1 / 15

SYS366

SYS366. Week 10, Lecture 3 Systems Requirements Gathering: Identifying Operating Requirements . Requirements. Needs and Features are informal. Needs , Features and Requirements represent different views of the system. Identifying Requirements.

porter
Download Presentation

SYS366

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. SYS366 Week 10, Lecture 3 Systems Requirements Gathering: Identifying Operating Requirements

  2. Requirements • Needs and Features are informal. • Needs, Features and Requirements represent different views of the system.

  3. Identifying Requirements • The Requirements view is provided by the product feature set and other high-level product requirements definitions.* • Bitner & Spence, p.74

  4. Identifying System Requirements • “A requirement is a desired feature, property or behavior of a system.” * * Unified Modeling Language

  5. Features “Features are not useful for defining the behavior of the system in precise enough terms to design, develop, or test the system.” * * Use Case Modeling, by Bittner & Spence, page 6.

  6. Identifying System Requirements • A requirement “is either derived directly from stakeholder or user needs Or stated in a contract, standard, specification, or other formally imposed document.” * * Use Case Modeling, by Bittner & Spence, page 5.

  7. Requirements Gathering • For an existing system, analyst needs to find out: • Functionality • what functionality of the existing system will be included in the new system • Data needs • what data from the existing system will need to be migrated into the new system

  8. Requirements Gathering • For a new system, analyst needs to find out: • Functionality • What are the activities the system needs to perform? • How is the user to interact with the system? • Are other systems to interact with the system? • Data needs • What information is needed?

  9. Operating Requirements • “the product (from the Product Position statement) to be produced results in requirements being placed on the operating environment in which it will be deployed” * • These operating requirements that must be met by the operating environment if the solution is to be successfully deployed.* * Use Case Modeling, by Bittner & Spence, page 79.

  10. Operating Requirements Operating requirements include • System Requirements • Operating Environment requirements * Use Case Modeling, by Bittner & Spence, page 79.

  11. System Requirements System requirements necessary to support the application, such as • Host operating systems • Network platforms • Configurations • Memory • Peripherals • Companion software • performance Use Case Modeling, by Bittner & Spence, page 79.

  12. Operating Environment Requirements For hardware-based systems • Location • Temperature • shock • Humidity Use Case Modeling, by Bittner & Spence, page 80.

  13. Operating Environment Requirements For software applications • Usage conditions • User environment • Resource availability • Maintenance issues • Error handling • Back up and Recovery Use Case Modeling, by Bittner & Spence, page 80.

  14. Operating Environment for one Business Area: Customer Support

  15. Operating Environment Requirements Exercise • Each group member is to develop 3 operating environment requirements for their Business area • The team is to develop 3 overall operating environment requirements for JAT. • The individual operating requirements plus the overall operating requirements are to be added to section II, E, of the PID. The team is responsible for ensuring that there is no duplication in the PID.

More Related