1. CMPT 275 Software 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
Janice Regan, 2008

3. Requirements Gathering/Specification6 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

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

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

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

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

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

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

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

11. SRS format for your term project - 1
Cover Page
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

12. SRS format for your term project - 2
Requirements Analysis
Scenarios (not “informal scenarios”) 4
Use Cases
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

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

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

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

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:
The names of a candidate
The party affiliations of that candidate
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

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

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