1 / 14

CMPT 275 Software Engineering

CMPT 275 Software Engineering. Requirements Analysis Phase Overview of Requirements Analysis Activity System Context Diagrams. Requirements Gathering/Specification. 6. 1. Project Description. 2. Software Developer. Client/User. 5. Informal Scenarios. 3. 7. Questions. 4. 8. 4.

kamana
Download Presentation

CMPT 275 Software Engineering

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. CMPT 275Software Engineering Requirements Analysis Phase Overview of Requirements Analysis Activity System Context Diagrams

  2. Requirements Gathering/Specification 6 1 Project Description 2 Software Developer Client/User 5 Informal Scenarios 3 7 Questions 4 8 4 8 Requirements Specification Document 3 7 4 Client meeting Client requirements review meeting 8

  3. Project: Requirements Analysis • Requirements gathering and specification will allow you to build an ‘analysis model’. This model represents the user’s/client’s view of the system • You will end up with a list of functional requirements. • Each requirement will represent one function/activity • This is your ‘analysis model’ • Functional requirements are not dependent on specific methods of implementation

  4. Project: Requirements Analysis • Your list of functional requirements will • Describe the required interactions between the system and its environment (independent of implementation) • You will also need a list of non-functional requirements • QUALITY REQUIREMENTS: Usability, reliability, performance, maintainability • CONSTRAINTS or PSEUDO REQUIREMENTS: Implementation (tools, languages), interface (to external systems), operation (admin, management), packaging, Legal

  5. Project: Requirements Analysis • You requirements must be • Complete: all required features must be described • Consistent: no two requirements in the specification may contradict each other • Unambiguous: no requirement can be interpreted in two different and contradictory ways • Correct: Only features desired by the client / developer are included not unintended extra features (problems)

  6. Class Project: Requirements Analysis • Next you will proceed using use case centered development (UCCD) to your requirements model • System Context Diagram • Identifying Actors and developing Use Cases • Primary classes • Use cases and Scenarios (formal and informal) • Use case Diagram • Class (object) Diagram • State Diagrams

  7. Requirements Analysis Activity Software Developer Client/User Update SRS Use Case Centered Development (UCCD) Questions Use Case Diagram Use Cases System Context Diagram Class Diagram Primary Classes Scenarios State Diagram

  8. Roles • Participants are people associated with the project (software system) • Client, developer, manager, end user • A set of related tasks that are assigned to a participant is a role • A student (role) is assigned a group of related tasks: registers in classes, receives grades • A teacher (role) is assigned a group of related tasks: gives classes, marks student work, gives grades

  9. Actor • Entity outside the software system • interacts with the system • Operates on objects in the system but cannot be operated upon by objects in the system. • Human, hardware device, another software system • Represents coherent role played by users • e.g.: In an automated registration system teacher, student, registrations data base

  10. Actor • A user of software system may take on more than 1 role, usually at different times • e.g.: Eva interacts with the system not only as a student actor but also as a teacher actor • Eva teaches math, but is a student of French • An actor may represent more than one user • e.g.: Both Eva and John may take the role of a student

  11. Primary and Secondary Actors • Primary Actors • Actors who initiate a scenario (use case) causing the system to achieve a goal • automated registration system example the student or teacher is a primary actor • Secondary Actors • Actors supporting the system so primary users goals can be completed (do not initiate the use case or scenario) • automated registration system example the registration data base is a secondary actor

  12. Primary and Secondary Actors • It is possible for an Actor to be a primary (initiating) actor in one scenario and a (non-initiating) or secondary actor in another scenario in the same system • For example in the automated registration system example • When Eva registers in a French class she is the primary actor (student) and the registration data base is the secondary actor. • Periodically the registration data base (primary actor) uses the registration data base to print notifications of registration to be sent to students.

  13. System Context Diagram: LMS Show how the software system interacts with its environment Librarian Resources (Books, CDs ..) Patron Software System Being created Employee Information Repository (DB) Web Libraries Resource Information Repository (DB) Online Journals Student Information Repository (DB)

  14. System Context Diagram: LMS Show how the software system interacts with its environment Librarian Resources (Books, CDs ..) Patron Software System Being created Web DB components are custom components developed specifically for this application and are thus part of this application Online Journals

More Related