Software Requirements Analysis and Specification in Project Development
"Learn how to gather and specify software requirements using an object-oriented paradigm for your class project. Explore the process of building an analysis model, defining functional and non-functional requirements, and ensuring completeness, consistency, and correctness in your specifications. Enhance your understanding of user/client perspectives and the importance of clear, unambiguous requirements in software engineering. Prepare for effective client meetings and reviews to drive successful project outcomes."
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
CMPT 275 Software Engineering Requirements Analysis Phase Requirements Specification Activity 1
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 2
Requirements Gathering/Specification 6 Project Description 1 2 Software Developer Client/User 5 Informal Scenarios 3 7 4 8 Questions Requirements Specification Document 4 8 3 7 Client meeting 4 Client requirements review meeting Janice Regan, 2008 3 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 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 Janice Regan, 2008 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) Janice Regan, 2008 6
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 7
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 8
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 9
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 10
SRS format for your term project - 1 Cover Page 2 Revision History Table of contents Requirements Specification Functional Requirements Prioritization of Functional Requirements Non-Functional Requirements (numbers indicate first deliverable in which the contents of the section are included.) 2 2 2 Janice Regan, 2008 11
SRS format for your term project - 2 Requirements Analysis Scenarios (not informal scenarios ) Use Cases Use Case diagram Class diagram User Interface Description 4 4 4 4 4 All sections prepared in deliverable 3 must be updated as necessary and included in deliverable 5 Janice Regan, 2008 12
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 13
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 14
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 15
Example: Functional Requirements 1. 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 16
Format for your SRS Please use the format on the previous slide for the requirements in your SRS Janice Regan, 2008 17
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 18
