COMSATS University Islamabad,

Abbottabad Campus

SOFTWARE REQUIREMENTS
SPECIFICATION
(SRS DOCUMENT)

for
HangMan : Vocabulary building app
Version 1.0

By
Ali Shozab Siddiqui CIIT/FA19-BCS-020/ATD
Sheraz Khan CIIT/FA19-BSE-160/ATD
Khurram Safi CIIT/FA19-BSE-147/ATD

Ma’am Nudrat Habib

Bachelor of Science in Computer Science (20xx-20xx)

 Table of Contents
Revision History.............................................................................................................................3
1. Introduction..............................................................................................................................5
1.1 Purpose.......................................................................................................................................5
1.2 Scope..........................................................................................................................................5
2. Overall description...................................................................................................................5
2.1 Product perspective....................................................................................................................5
2.2 Design and implementation constraints......................................................................................5
3. Requirement identifying technique........................................................................................6
3.1 Use Case Diagram......................................................................................................................6
3.2 Use Case Description.................................................................................................................6
4. Specific Requirements.............................................................................................................8
4.1 System feature X........................................................................................................................8
5. Quality attributes.......................................................................Error! Bookmark not defined.
5.1 Usability.....................................................................................................................................9
5.2 Performance...............................................................................................................................9
6. External interface requirements...........................................................................................35
6.1 User interfaces..........................................................................................................................35
6.2 Software interfaces...................................................................................................................35
6.3 Hardware interfaces..................................................................................................................35
6.4 Communications interfaces......................................................................................................35
7. Project Gantt chart................................................................................................................35
8. References...............................................................................................................................10

2
 Revision History
Name Date Reason for changes Version
Modes Implementation of easy mode and 3 levels
Jira Jira report submission.

3
 Application Evaluation History

Comments (by committee) Action Taken

*include the ones given at scope time both in doc and
presentation
Implementation of easy mode with 3 levels. Yes
Jira report submission. Yes

Supervised by
<Supervisor’s Name>

Signature______________

4
 1. Introduction
The game is made on the basic concept of hangman. A word is given at random for the player to guess.
They have a total of 10 chances to guess the word. If the users guess the word correctly they receive a
couple of coins and if they run out of chances than they lose the level and coins from their total score.
When the word is guessed correctly the game will display its meaning and some basic information for
the user. By this way the user will learn and have fun at the same time.

Purpose
The target of this game is mainly youngsters. Youngsters these days enjoy short and quick games. The
main object of this game is to use just that fact. The game will be short and fast so the user doesn’t get
bored. Upon guessing the word correctly the fact will be displayed. The user will learn a new word with
its description and meaning increasing their vocabulary in-directly. The game is education based. The
purpose of this game is also to avoid the users specially teenagers from wasting their precious time in
useless or time wasting games. The game can help increase knowledge as well with facts and figures. It
helps to increase the general knowledge of the user.

Scope

The game is still in the early stages. So there are not many words in each category. The library is
however not small at the moment. It has approximately over 120 words in its vocabulary. It also has
150+ facts and figures about the words to educate the user. The game is being further updated. The
game will have a wider vocabulary in the future. Also more categories will be added. To make the game
more fun bonus levels will be added. The user will have more to learn and increase their general
knowledge more.

2. Overall description
Product perspective

The benefit of this program is primarily that it allows someone to play as a solitaire game
without requiring another person to participate.

Product Features

The application's purpose is to simulate the word game "Hangman."   The major
features are:

 Obtain a hidden word.

5
  Manage the game play: getting the player guess, evaluating it, and updating the
game score.
 Determining if the game is won or lost.

Design and implementation constraints

Design

 System Flowchart

The system flow charts give an overview of the entire project. It shows the working and possible
conditions the users might face during the game.

6
 Work Breakdown Structure

7
8
9
 Entity Relationship Diagram (ERD)

10
 Data Flow Diagram (DFD)

11
 Class Diagram

12
 State Chart Diagram

13
  Implementation

3. Requirement identifying technique

As per Player’s request, when the game is opened the main menu is displayed with the options of
“Play”, “Settings”, “Player” and “Exit”. When the user selects the play option, they are required
to select a difficulty level. Then the categories of the related difficulties are displayed the user
chooses the one they seem fit. The word is displayed and they user makes the guesses. On wrong
guesses the errors are increased. When the errors reach the set limit the losing message is
displayed and total score is displayed. Late the user is regarded to the menu to take further
course.

FR01: Open the Application.

14
FR02:User can select modes depending on difficulty

• Easy(30% presentation)

• Classic (60% presentation)

• Pro (100% presentation)

FR03:User Gets word description at end of game

FR04:Only a limited number of guesses is allowed – a correct guess is not counted.

FR05:The player keeps guessing until:

The complete word is shown (the user wins) OR

The player runs out of guessing (the user loses)

Use case diagram

15
Use case description
Player
The actor can play the game, change the player, change settings and exit the game. To guess the word the
player must fill its pre requirements by selecting play, selecting a difficulty and game starts .

System
The system has the task of storing the player record, updating their score during the game and displaying
the result.

 Starting the application.

 Select modes.
 Playing a game.
 Ending the game.

Table 1 Show the detail use case template

Use Case ID: Enter a unique numeric identifier for the Use Case. e.g. UC-1
Use Case Enter a short name for the Use Case using an active verb phrase. e.g.
Name: Order a Meal
Actors: [An actor is a person or other entity external to the software system being
specified who interacts with the system and performs use cases to accomplish
tasks.] e.g.
Primary Actor: Patron Secondary Actors: Cafeteria Inventory System

Description: [Provide a brief description of the reason for and outcome of this use case.] e.g.
A Patron accesses the Cafeteria Ordering System from either the corporate
intranet or external Internet, views the menu for a specific date, selects food
items, and places an order for a meal to be picked up in the cafeteria or delivered
to a specified location within a specified 15-minute time window.
Trigger: [Identify the event that initiates the use case.]e.g.
A Patron indicates that he wants to order a meal.
Preconditions: [List any activities that must take place, or any conditions that must be true,
before the use case can be started.
PRE-1. Patron is logged into COS.
PRE-2. Patron is registered for meal payments by payroll deduction.
Postconditions: [Describe the state of the system at the conclusion of the use case execution.
POST-1. Meal order is stored in COS with a status of “Accepted.”
POST-2. Inventory of available food items is updated to reflect items in this
order.
POST-3. Remaining delivery capacity for the requested time window is updated.
Normal Flow: [Provide a detailed description of the user actions and system responses that will
take place during execution of the use case under normal, expected conditions.
1.0 Order a Single Meal
1. Patron asks to view menu for a specific date. (see 1.0. E1, 1.0.E2)
2. COS displays menu of available food items and the daily special.
3. Patron selects one or more food items from menu. (see 1.1)

16
 4. Patron indicates that meal order is complete. (see 1.2)
5. COS displays ordered menu items, individual prices, and total price, including
taxes and delivery charge.
6. Patron either confirms meal order (continue normal flow) or requests to modify
meal order (return to step 2).
7. COS displays available delivery times for the delivery date.
8. Patron selects a delivery time and specifies the delivery location.
9. Patron specifies payment method.
10. COS confirms acceptance of the order.
11. COS sends Patron an email message confirming order details, price, and
delivery instructions.
12. COS stores order, sends food item information to Cafeteria Inventory System,
and updates available delivery times.
Alternative [Document legitimate branches from the main flow to handle special conditions
Flows: (also known as extensions). For each alternative flow reference the branching
[Alternative
step number of the normal flow and the condition which must be true for this
Flow 1 – Not in
Network] extension to be executed. e.g.
1.1 Order multiple identical meals
1. Patron requests a specified number of identical meals. (see 1.1. E1)
2. Return to step 4 of normal flow.
1.2 Order multiple meals
1. Patron asks to order another meal.
2. Return to step 1 of normal flow.
Note: Insert a new row for each distinctive alternative flow. ]
Exceptions: 1.0. E1 Requested date is today and current time is after today’s order cutoff time
1. COS informs Patron that it’s too late to place an order for today.
2a. If Patron cancels the meal ordering process, then COS terminates use case.
2b. Else if Patron requests another date, then COS restarts use case.
1.0. E2 No delivery times left
1. COS informs Patron that no delivery times are available for the meal date.
2a. If Patron cancels the meal ordering process, then COS terminates use case.
2b. Else if Patron requests to pick the order up at the cafeteria, then continue with
normal flow, but skip steps 7 and 8.
1.1. E1 Insufficient inventory to fulfill multiple meal order
1. COS informs Patron of the maximum number of identical meals he can order,
based on current available inventory.
2a. If Patron modifies number of meals ordered, then return to step 4 of normal
flow.
2b. Else if Patron cancels the meal ordering process, then COS terminates use
case.
Business Rules Use cases and business rules are intertwined. Some business rules constrain
which roles can perform all or parts of a use case. Perhaps only users who have
certain privilege levels can perform specific alternative flows. That is, the rule
might impose preconditions that the system must test before letting the user
proceed. Business rules can influence specific steps in the normal flow by
defining valid input values or dictating how computations are to be performed
e.g.

17
 BR-1 Delivery time windows are 15 minutes, beginning on each quarter hour.
BR-2 Deliveries must be completed between 11:00 A.M. and 2:00 P.M. local
time, inclusive.

Note: If you are maintaining the business rule in a separate table in SRS then only
mention here their IDs.

Assumptions: [List any assumptions.

1. e.g. Assume that 15 percent of Patrons will order the daily special (Source:
previous 6 months of cafeteria data).

4. Specific Funtional Requirements

FR01: Open the Application.

FR02:User can select modes depending on difficulty
• Easy(30% presentation)
• Classic (60% presentation)
• Pro (100% presentation)
FR03:User Gets word description at end of game
FR04:Only a limited number of guesses is allowed – a correct guess is not counted.
FR05:The player keeps guessing until:
The complete word is shown (the user wins) OR
The player runs out of guessing (the user loses)

5. Quality attributes

The game consists of simple programming codes without too much complicated coding. It
follows the standard coding procedure. The game is easily modifiable so making updates and
changes is fairly simple.

18
 Usability

1. A new user should be able to play a complete game of hangman in less than ten minutes.

2. A new user should commit less than one error in use of the game (e.g. selecting the
wrong letter) every ten minutes.

3. A user who is familiar with the rules of Hangman be able to correctly operate the
program without any written documentation.

Performance

The game consists of low MB assets, so the total memory of the game is low. This way more
users can download the game as it doesn’t take much space. It is fast and consumes less time and
it also has a high throughput.

6. External interface requirements

The Hangman vocabulary game and the Word Server will communicate via standard
internet socket communication.

The design of the user interface to the Hangman vocablory game must conform to the
HangmanUI interface provided 

User interfaces
When started, Word Server must display a message indicating the host address on which it is
running

Software interfaces
Hardware interfaces Communication interfaces

7. Project Gantt Chart

8. References
List any documents or other resources to which this SRS refers, if any. These might include user
interface style guides, standards, system requirements specifications, interface specifications, or
19
the SRS for a related product.

20