Project Analysis Course (2012-2013) : Week 2 Activities

Project Analysis Course (2012-2013)
Week 2 Activities
Where we are now?
 At the end of week 1, we are familiar
with :
 General description of project area
(problem area)
 Project scope (geographically,
technically, borders,..)
 Selecting Technics
 Intended users of the system
 Project Context
Where we go?
Identify requirements (end user point of
view) & analyze (Developer point of view)
them
Focus of this week includes:
 Identification of functional
requirement of the system
 Identification of the non functional
requirement of the system
 Identification of constraints
 Prioritize requirements
 Validate
 use case modelling
Functional Requirement
 Study the project case carefully and identify functional
requirements
Functional requirements describe the interactions between
the system and its environment ( in short: WHAT WILL THE
SYSTEM DO)
 try to identify all possible FR of the system at this stage.
Stating Functional requirements, examples:
1. An operator must be able to define a new game.
2. The system will provide registration of new students
3. The system shall keep track of library members
 Remember FR are phrased as actions

“Advertise a new league”
“Schedule tournament”
“Notify an interest group
Non Functional Requirement
Aspects not directly related to functional behavior, but part of
the system
Stating non functional requirements, examples:
1. The response time of the system must be less than 1
second
2. The system must recover from failure in less than an
hour
NFR Categories:
- Usability
- Reliability Usability Requirement example:
Robustness “Viewers must be able to watch a match without prior registration and
Safety without prior knowledge of the match.”
- Performance
Response time Performance Requirement example
Scalability “The system must support 10 parallel tournaments”
Throughput
Availability Supportability Requirement example
- Supportability “The operator must be able to add new games without modifications to
Adaptability the existing system.”
Maintainability
Constrains
Imposed by the client or the environment
Sample constraints requirements:
1. The system must be implemented in
Java
2. The system should run under windows
operating system only
Prioritize Requirements
From all identified FR & NFR, which are the
most important one (must develop)
Rewrite FR & NFR omitting the non important
requirements
e.g.: for student registration system
ALL discovered requirements

1. Register students
2. Manage students (add, delete, update) Most important updated are 1,
3. Attend lectures 2, 4
4. Assign courses 3 is not part of the registration
5. ……. hence- not important requirement
Validate Requirements
Activities:
 Recall the different roles in the groups
( users, developers, etc) - Ask
users/clients if the current
requirements conform their defined
requirements
 Go online check for similar project
cases implementation – see the match
use cases
Activities includes:
 Identification of main
actors/stakeholders of the system
 Identifying functions provided by the
system to each actor/stakeholder
 Draw use case diagrams (Check if there
is relationship between use cases, show
it)
 Provide use case scenarios
 Provide full description of use case
use cases…….
Identification of Main actors
Example 1 : For Online examination
system, actors include:
Examiner
Examinee (students)
System Administrator
use cases………
Identifying functions provided by the system to
each actor
Example 1 : For Online examination system,
actors include:
Examiner (prepare exam, mark exam, display
results)
Examinee (register for an exam, submit exam,
view results)
System administrator (manage users, manage
exams)
use cases………
Draw use case diagrams (Check if there is relationship between use cases, show
it)
Online Exam System
prepare exam
mark exam
examiner
display results
register for exam
submit exam
examinee
view results
manage exams
system administrator manage users

use cases………
Provide use case scenarios
•For above example lots of scenarios can be
generated
•Scenarios come from use cases, example
Scenario 1: register for exam
Scenario 2: manage users
Scenario 3: manage exams
Scenario 4: display results
•Provide a sequence of steps involved in each
scenario
use cases………
Provide use case scenarios
•Example: Scenario 1- register for exam
(steps)
1. Examinee fills registration form
2. Examinee submits the form
3. The system verifies payment for
exam
4. The system returns a success
registration message
•Do the same for all scenarios
use cases………
Provide full description of use case ( e.g. add a record of a TB patient to
database
Use Case Name - Add a person record
Purpose: This business use case will allow a user to add a "person record"
to the Master Person Index (MPI).
Pre-conditions: (Those conditions that must be present before the use

case can start.)
The user must have proper security rights to enter a patient in the system.
System is available and operable
The user is notified that a person requires TB services and the person
satisfies jurisdiction criteria for assessment and/or treatment.
The person requires TB assessment and/or treatment needs to be added
into the MPI.
Main Flow:
1. User selects register option
2. System displays register screen
3. User enters basic patient information in the register screen. Basic information
may include last name, first name, sex, date of birth, address, and if a
translator is needed.
4. User enters the reason for adding the person to the MPI which may have the
following values: suspect case, confirmed case, contact investigation, targeted
testing, etc.
5. User selects the save option
6. System saves registration in the MPI
7. End Use Case
Alternate Flow/ Exception: (An optional situation within the activity flow.)
8. The system provides a message that a database record arleady exist
9. System rejects the registration and stops
Post-conditions: (Outcome)
A person record is created in the MPI.
This week’s presentation Content
Heading: Requirement Elicitation & Analysis (summary

report)
1. Introduction (elicitation & analysis approaches)

2. Functional Requirements
3. Non Functional Requirements
3.1 security
3.2 performance
3.3 …………
4. Constraints
5. Use case model
5.1 Actors
5.2 Use case diagram
5.3 use cases specification
This week’s report Content
Heading: Requirement Elicitation & Analysis (detailed

report)
1. Introduction (elicitation & analysis approaches)

2. Functional Requirements
3. Non Functional Requirements
3.1 security
3.2 performance
3.3 …………
4. Constraints
5. Use case model
5.1 Actors
5.2 Use case diagram
5.3 use cases specification

Project Analysis Course (2012-2013) : Week 2 Activities

Uploaded by

Copyright:

Available Formats

Project Analysis Course (2012-2013) : Week 2 Activities

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Analysis Course (2012-2013) : Week 2 Activities

Uploaded by

Copyright:

Available Formats

Project Analysis Course (2012-2013)

 Remember FR are phrased as actions

ALL discovered requirements

register for exam

system administrator manage users

Pre-conditions: (Those conditions that must be present before the use

Heading: Requirement Elicitation & Analysis (summary

1. Introduction (elicitation & analysis approaches)

Heading: Requirement Elicitation & Analysis (detailed

1. Introduction (elicitation & analysis approaches)

You might also like