POLITEHNICA UNIVERSITY OF BUCHAREST

SOFTWARE ENGINEERING

Hangman Game
Software Requirements Specification

Team:
Anne-Lise Griveau, 1262E
Maywadee Soytong, 1262E
Coordinator:
Dr. Ing. Goga Nicolae

Date created:
Monday, December 15, 2014

Delivery report

Delivery Report
(will be delivered along with the project)
Name

Group

Project implementation [%, reason]

_______________

______

____________________________ _________
____________________________
____________________________

_______________

______

____________________________ _________
____________________________
____________________________

_______________

______

____________________________ _________
____________________________
____________________________

Delivery date:
__________________________________

Signature

SRS

Table of Contents
POLITEHNICA UNIVERSITY OF BUCHAREST..........................................................1
SOFTWARE ENGINEERING..................................................................................1
DELIVERY REPORT............................................................................................2
TABLE OF CONTENTS.........................................................................................3
REQUIREMENTS ANALYSIS..................................................................................5
1. Introduction....................................................................................................................5
1.1. Purpose...................................................................................................................5
1.2. History.....................................................................................................................5
1.3. Scope......................................................................................................................5
1.4. Definitions, Acronyms and Abbreviations...............................................................5
1.5. References..............................................................................................................5
1.6. Structure..................................................................................................................5
2. General description.......................................................................................................6
2.1. Product Description.................................................................................................6
2.2. Product Functions...................................................................................................6
2.3. User description......................................................................................................6
2.4. Constraints..............................................................................................................6
2.5. Assumptions and Dependencies............................................................................6
3. System Requirements...................................................................................................7
3.1. External Interface Requirements............................................................................7
3.2. Functional Requirements........................................................................................7
3.3. Performance Requirements....................................................................................8
3.4. Design Constraints..................................................................................................8
3.5. Software System Attributes.....................................................................................8
3.6. Other System Requirements..................................................................................8

APPENDICES.....................................................................................................9
A1. Interview with the customer........................................................................................9
A2. System diagram..........................................................................................................9
A3. Use Cases Diagram....................................................................................................9
A4. Class Diagrams...........................................................................................................9
A5. Sequence Diagrams....................................................................................................9
A6. State Diagrams.........................................................................................................10
A7. Document Evolution..................................................................................................10
A8. Report regarding team meetings..............................................................................10
A9. Conclusions regarding the activity............................................................................10

SRS

Requirements Analysis
According to the IEEE STD-830-1993, IEEE Recommended Practice for Software Requirements
Specification.

1. Introduction
1.1. Purpose
The purpose of this document is to describe the software requirements for a Hangman game application.

1.2. History
This project doesnt represent a sequel of a functional project.

1.3. Scope
The hangman game is a game application whose purpose is to have the player guess a word by finding its
letters in a certain number of moves.
Its application field is games with a very slight educative note as this game can also help younger players to
better their spelling of common words.

1.4. Definitions, Acronyms and Abbreviations

This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly
interpret the SRS. This information may be provided by reference to one or more appendices in the SRS or
by reference to other documents.

1.5. References
[1] Dr.ir.N.Goga, Lecture Software Engineering, Polytechnic University of Bucharest, October 2014
[2] prof. Luca Dan Serbanati, Lecture Software Design Techniques, Polytechnic University of Bucharest,
October 2014
[3] Hangman (game), http://en.wikipedia.org/wiki/Hangman_(game), 26 October 2014, last visited 5
November 2014

1.6. Structure
The introduction of this document describes its purpose, scope and history of the project.
The General Descrition chapter describes the product resulting from the project and its usages.
The System Requirements chapter gives more details about the interface and functionalities of the final
products, as well as the different design constraints that should be respected.
The Appendices contain the UML diagrams that complement the system requirements chapter.

SRS
2. General description
2.1. Product Description
The product that will result from the project will be a game application of the hangman game. Its purpose will
be to entertain the player while improving his spelling ability.
Maintenance by adding new words to be guessed will be easy as the dictionary of words will be contained in
a simple file.
The interface should have few explicit buttons so as to be easily understood by the player.
This way the player will be able to start enjoying the game immediately without having to make efforts to
understand the way the game works.

2.2. Product Functions

The product consists of a game application to be run on the personal computer of the user.
This game goal is to make the player guess a word by having him propose letters. In case the proposed
letter doesnt belong to the word a hangman starts to be drawn. The game is over when the payer finds the
word or when the hangman is completely drawn.
This game does not require the user to have special credentials or computing skills to be used.

2.3. User description

This game is for anyone that would like to relax.The player can choose between three levels of difficulty to
have the best experience possible.
For example the easy difficulty could be used mostly by children while the hard mode will be used by adults
looking for some challenge.

2.4. Constraints
The application is a one player game.
We want the application to return the expected results in order not to spoil the fun of the player.

2.5. Assumptions and Dependencies

The application is to be run on personal computers. The files containing the data are in the same directory
as the executable. There is no need for extra software to be installed to use the application.

SRS
3. System Requirements
3.1. External Interface Requirements
User interface
The interface of the application is unique, it is the same for every user.
Hardware interfaces
The player interacts with the application using the classical input and output devices such as mouse,
keyboard, and computer screen.
Software (libraries or other parts/programs) interfaces
The application uses Java for the communication with the data files. In this way a high portability of
the sys application tem is assured, the only software interface needed being the one with JVM (Java
Virtual Machine) which can be easily installed on the common operating systems (Windows, Linux,
MacOS).

3.2. Functional Requirements

The user can interact with the application through the graphical interface on the computer.
The player starts a new game while choosing between three difficulty levels : easy, normal, hard.
Based on the difficulty selected the application selects a word and displays a number of
underscores representing each letter of the word and the number of hints required
- A description of the word and a letter of the word for easy
- A letter belonging to the word for normal
- No help for hard
The player can then propose a letter. If the letter belongs to the word, the application displays all of
them in place of their corresponding underscore. If the letter doesnt belong to the word the
application draws a body part of the hangman.
The game finishes when the hangman is fully drawn or when the player correctly guesses the word.
At all times the already proposed letters are displayed.
The player can select and start a new game at anytime.
Use cases
Use case : Start a new game
Use case description : A player wants to start a new game.
Player
1. Select difficulty level

Application
2. Select a word and display underscores
3. Display the hints corresponding

Use case : Proposing a character

Use case description : The players proposes a character
Main flow of events
Player
1. Input a character

Application
2. Display the character in place of
corresponding underscores (A)
3. Update the already proposed letters list

Alternate flow of events

A : Draw a part of the hangman
A.1 : Go to 3.
Use case : Ending a game
Use case description : The player ends the game

SRS
Main flow of events
Player
1. Input final character

Application
2. Display the completed word

3. Display Congratulations window (A1)

4. Select new game (A2)
5. Start new game
Alternate flow of events
A1: Display completed hangman
A1.1 : Display Losing window
A1.2 : Go to 4.
A2 : Exit application

3.3. Performance Requirements

The application should be able to parse the dictionary of words in less than 2 seconds in order not to
make the player wait to much. A long waiting time would ruin his fun.

3.4. Design Constraints

The design of the application should limit it to the use of Java in order to ensure the needed
portability. Also the application should be designed with an interface with few buttons accompanied
with a description when needed in order for non-experienced users to be able to use it without
difficulties.

3.5. Software System Attributes

Trust
There is no critical data stored within the game. No critical information will be lost in case of system
failure.
Reliability
The application is able to work whenever the player lauches it.
Security
There is no critical data stored within the game thats why no account or credentials are requirered
to use the game.
Maintenance
The maintenance of the application is designed to be easy. New words can be directly added at the
end of the dictionary file as long as they respect the same writing norm as the already existing
words.
Portability
The portability of the application is high because it uses Java for implementation. The Java Virtual
Machine needed for java code to be run can be easily installed on the usual operating systems
which are supported by the usual computer architectures.
Fault tolerance
The application checks for input errors by the player. In the case of an error the player is notified but
the application doesnt crash, it follows the requirements needed for a graceful degradation,
maintaining the other functionalities of the application.

3.6. Other System Requirements

SRS

Appendices
A1. Interview with the customer
A2. System diagram
A3. Use Cases Diagram

A4. Class Diagrams

A5. Sequence Diagrams
Start new game use case

SRS
Propose character use case

End game use case (Alternative end A2)

A6. State Diagrams
A7. Document Evolution
A8. Report regarding team meetings
Date: 1 11 2014
Location:
Participants: Anne-Lise Griveau, Maywadee Soytong
Summary: work on SRS document
Activity:
Title
Description (4 lines)
Results:
Element
Description (2-3 lines)

A9. Conclusions regarding the activity

This project allowed us to have a better understanding about the firsts steps of a real project by
giving us a simple and concrete example.
Through this project, we were also able to better our teamwork, which is an essential skill for any engineer.