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 Janice Regan, 2008

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

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 Janice Regan, 2008

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 Janice Regan, 2008

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) Janice Regan, 2008

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 Janice Regan, 2008

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) Janice Regan, 2008

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 Janice Regan, 2008

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 Janice Regan, 2008

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.) Janice Regan, 2008

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 Janice Regan, 2008

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. Janice Regan, 2008

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 Janice Regan, 2008

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 Janice Regan, 2008

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 Janice Regan, 2008

Format for your SRS Please use the format on the previous slide for the requirements in your SRS Janice Regan, 2008

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 Janice Regan, 2008