SDD (Hangman)

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 23

COMSATS University Islamabad,

Abbottabad Campus

SOFTWARE DESIGN
DESCRIPTION
(SDD DOCUMENT)

for
<HANGMAN>
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

Supervisor
Mam Nudrat Habib

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

1
Table of Contents
Revision History.............................................................................................................................3
1. Introduction..............................................................................................................................5
2. Design Methodology and software process model................................................................5
3. System Overview......................................................................................................................5
3.1 Architectural Design...................................................................................................................5
3.2 Process Flow/Representation......................................................................................................5
4. Design Models [along with descriptions]...............................................................................5
5. Data Design...............................................................................................................................6
5.1 Data Dictionary..........................................................................................................................6
6. Algorithm & Implementation.................................................................................................6
7. Software Requirements Traceability Matrix........................................................................6
8. Human Interface Design..........................................................................................................7
8.1 Screen Images.............................................................................................................................7
8.2 Screen Objects and Actions..............................................................................................................7
9. Appendix I................................................................................................................................7

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
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.

Scope

The game is still in the early stages. So, there are not many words in each category. The library is
however not small now. 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.

Design methodology and software process model

We have used Object-oriented design (OOD) which is the process of using an object-
oriented methodology to design an application.

We have developed this Android Application using agile methodology. Reason behind agile
methodology is because our project functionalities are dependent on each other, and we also
need to improve functionalities after user feedback. So, agile development methodology used to
minimize risk while adding new functionality or changing previous functionalities. In this
method, we developed this project in iterations which contain addition of the new functionalities.

 System overview
Give a general description of the functionality, context and design of your project.
Provide any background information if necessary.

5
Architectural design

Deployment Diagram

6
Process flow/Representation
Provide a representation of the flow of MAJOR processes of your system in the form of an
activity diagram. DO NOT CREATE ACTIVITY DIAGRAMS FOR LOGIN OR SIGN-UP
UNLESS THEY INVOLVE SIGNIFICANT COMPLEXITY. Include only the major
processes.

Design models [along with descriptions]


The applicable models may include:

7
Class Diagram

8
Sequence Diagram

a. Correctly guess a character but still need to continue playing

9
b. Correctly guess a character and win

c. Incorrectly guess a character but still need to continue playing

d. Painting the body parts

10
e. The game is lost when the noose is drawn 

 State Transition Diagram

11
Data Flow Diagram

 Schematic diagram (Hardware projects only)


 Timing diagram (Hardware projects only)

12
Insert applicable system models here.

You should be clear about all the concepts used in your diagrams for example for class diagram
you should know about aggregation, composition, and inheritance/generalization. Also ensure
visibility of all diagrams.

Class diagram and associated models shall only be necessary for object-oriented approach. In
case of procedural, create a DFD. Data flow diagram should be extended to 2-3 levels. It should
clearly list all processes, their sources/sinks and data stores.

Note: System design should be complete in all aspects. Create any/all diagrams if you need
to. A DFD can also be supplemented by a State Transition Diagram depending on the
nature of the project.

Hardware projects can include Schematic diagram, System block diagram, timing
diagram, Flow charts as replacement of sequence diagram/ Data flow diagram AFTER
CONSULTATION WITH THEIR SUPERVISORS. Choice of models must be properly
justified.

Data design 
Explain how the information domain of your system is transformed into data structures.
Describe how the major data or system entities are stored, processed, and organized.

List any databases or data storage items.

Data dictionary
Alphabetically list the system entities or major data along with their types and descriptions. If
you provided a functional description, list all the functions and function parameters. If
you provided an OO description, list the objects and its attributes, methods
and method parameters.

Algorithm & Implementation


In this section, we take a closer look at what each component does in a more systematic way.
Provide a summary of your algorithm for each function listed in procedural description language
(PDL) or pseudo code.

If you gave an OO description, summarize each object member function for all the objects


listed in PDL or pseudo code. Describe any local data when necessary.

Software requirements traceability matrix


This section should contain a table that summarizes how each software requirement has been met
in this document. The tabular format permits one-to-one and one-to-many relationships to be
shown.

13
Table 1 Requirements Traceability Matrix
Req. Number Ref. Item Design Component Component Items
FR01 Class Diagram ClassName FunctionName(s)
OR
FR01 DFD DiagramNumber/Level FunctionName(s)

Human interface design 
Describe the functionality of the system from the user’s perspective. Explain how the user will
be able to use  your system to complete  all the  expected  features and  the  feedback 
information that will be displayed for the user.

14
Screen images

15
16
17
18
19
20
21
8.2 Screen objects and actions
A discussion of screen objects and actions associated with those objects

Appendix I
 How to design using UML (OOP): For guidance please follow the instructions mentioned
in the link: http://agilemodeling.com/artifacts/

 How and when to design ER diagrams: For guidance please follow the instructions
mentioned in the link:
http://people.inf.elte.hu/nikovits/DB2/Ullman_The_Complete_Book.pdf

22
 Data flow diagrams: For guidance please follow the instructions mentioned in the link
and book:
o http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm
o Software Engineering –A Practitioner’s approach by Roger Pressman
 Architecture diagram: For guidance please follow the instructions mentioned in the link
and book:
o Ian Sommerville – Software Engineering 9th Edition– Chapter 6

23

You might also like