1 / 18

CMPT 275 Software Engineering

CMPT 275 Software Engineering. Requirements Analysis Phase Requirements Specification Activity. Project: Requirements Analysis. You will be using an object oriented paradigm for your class project Informal scenarios will be used to help you derive your software requirements specifications.

livia
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 Requirements Specification Activity

  2. Project: Requirements Analysis • You will be using an object oriented paradigm for your class project • Informal scenarios will be used to help you derive your software requirements specifications

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

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

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

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

  7. Project: Requirements Analysis • Later you will proceed using use case centered development (UCCD) to analyze your requirements and assure that they are complete consistent, unambiguous and correct • System context diagram • Identifying actors • Identifying Primary classes (initial analysis objects) • Identifying Scenarios and Use Cases • Identifying Relationships between use cases and actors. Using these relationships to build the use case diagram • Identifying relationships between classes and building a Class (object) diagram

  8. Project Deliverable #2 - #4 • Deliverable #2 is a partial Requirements Specification Document, version 1 • Deliverable #3 is a “client requirements review" done with your client • Deliverable #4 is a completed System Requirements Specification (SRS)

  9. Steps in requirements analysis - 1 • For your project • Clarify requirements in your first client meeting • Write a list of requirements in the needed format (discussed later), to be included in deliverable 2 • Begin your requirements analysis based on the list of requirements you made for deliverable 2 • Your requirements analysis will be added to the SRS you submitted as deliverable 2 (remember to update your revision history and requirements) to give the SRS you will submit as deliverable 4

  10. Steps in requirements analysis - 2 • For your project • Your requirements analysis will also help you to determine a list of more detailed questions and a list of use cases you can use to explain the context of those questions • Your requirements review meeting will allow your group to present the use cases you developed and ask the related detailed questions • Use the information you discover in the requirements review meeting to update the requirements analysis already added to your SRS before submitting your SRS as deliverable 5

  11. SRS format for your term project - 1 • Cover Page 2 • Revision History 2 • Table of contents 2 • Requirements Specification 2 • Functional Requirements • Prioritization of Functional Requirements • Non-Functional Requirements (numbers indicate first deliverable in which the contents of the section are included.)

  12. SRS format for your term project - 2 • Requirements Analysis • Scenarios (not “informal scenarios”) 4 • Use Cases 4 • Use Case diagram 4 • Class diagram 4 • User Interface Description 4 • All sections prepared in deliverable 3 must be updated as necessary and included in deliverable 5

  13. Requirements Specification • Format: • Requirements specifications are given in a structured format • requirements are numbered. • Finer details are shown as subsections • Finer details within subsections are shown as subsections of subsections ... • Functional and non-functional requirements are listed separately. Both lists use the same format. • For your term project you will compile a detailed list of functional and a detailed list of non-functional requirements using this format. These lists can then be checked for traceability.

  14. List of Requirements • The requirements you discover become part of a document • Documents are important, so you can refer to them and so new members and other members can refer to them • The software engineering document that includes the project requirements is usually called the Software Requirements Specification Document or SRS

  15. An example system • A system that manages an election • The system tabulates the votes that the voters have cast • The system determines who has won the election • The system archives information about candidates (people competing in the election), and about people managing the election

  16. Example: Functional Requirements • Update Riding Information 1.1 An election official can update any or all of the following information for any chosen riding: 1.1.1 The names of a candidate 1.1.1.1 The party affiliations of that candidate 1.1.2 A map of the riding 1.1.3 The number of eligible voters in the riding 1.1.4 The number of representatives for the riding 1.2 An elections official will update one riding at a time 1.3 An elections official may preview her changes before saving them in the riding repository

  17. Format for your SRS • Please use the format on the previous slide for the requirements in your SRS

  18. Clarifying the Requirements: • Other questions need to be answered to specify detailed requirements. For example: • What sort of Human computer interface is needed? • Are there any other pieces of data that need to be recorded or updated? • What is the maximum number of candidates in a riding? • Can the same candidate run in more than one riding? • And so on • Answers to such questions may raise additional questions so this is by nature an iterative process

More Related