DESIGN CRITIQUE ON

FAMILY TREE MOBILE APP

What is Software Design Document?
A software design document (SDD) is a written description of a software
product, that a software designer writes in order to give a software development
team an overall guidance of the architecture of the software project.
There are two kinds of design documents called HLDD (high-level design
document) and LLDD (low-level design document).

Why is Software Design Document

Required?
Requirement Traceability
Developer Blueprint
System Architecture Finalized
Project Member Training
Allowing for increased accuracy in time estimates
Allowing for content adjustments
 Why To Critique Design?
Lets us understand it by a real world example in
which a person lost his business !!!
The 4 essentials of a design critique
1. Overview
Initial reactions: What is your first impression of the design?
Content: Is everything present that should be included in the design?
Aesthetics: What is the total overall effect? Does it feel right?
Style: Does the design style seem appropriate for the stated goal or purpose?

2. Analysis
Layout: Does everything seem to be in the right place?
Flow: Does the content appear in a natural and logical progression?
Usability: Is it easy to use or interact with the design solution?
Typography: Does the type feel appropriate in tone?
Color: How is color used? What effect does it have in terms of conveying the
desired message?
Completeness: Is anything missing? Conversely, is anything there that
shouldnt be?
ThE 4 EssEnTIALs OF A dEsIgn cRITIquE.

3. Interpretation
Audience: How do you think the target audience will respond to this
solution? Why? Why not?
Details: Is the use of these particular graphic elements consistent with the
goals of the project? Why? Why not?
Problem areas: What things in this solution are not as effective as they
could be? Why do you think that?
Appeal: Is this an effective and appealing design for the context it will
live in? Why? Why not?

4. Evaluation
Brief: Does this design fulfill the creative brief. If not, why not?
Judgment: Given the answers to the above, does this design work?
Specifications Considered For Design
Critique
For Critiquing a design document should be:
Complete - No information is missing
Clear - Every sentence's meaning must be clear to all parties
Consistent - The writing style and notation is consistent throughout the
document and the document does not contradict itself.
Verifiable - All facts stated are verifiable

Document Structure should be in the format given by IEEE.

i.e. IEEE P1016/D5.0; 12 December 2005
IEEE Draft Standard for Software Design Descriptions
 Structure of Design Document
Provide a cover page that includes the phase, name, and
the current date.
sTRucTuRE OF dEsIgn dOcuMEnT.

Need a history table for SDD and figure information should be

provided, definition, acronomy, abbreviation are not mentioned, if
above details are not present then its hard to read and understand
document.
 Purpose is Not Clear!
Purpose should consist of requirements on the information content and
metadata organization of SDDs. It should specify requirements for the
selection of design languages to be used for software design description,
and requirements for documenting design viewpoints to be used in organizing a
software design description.
sYsTEM OvERvIEw shOuLd cOnsIsT OF
Briefly introduce the system context and design, and
discuss the background to the project. Give a general
description of the functionality , context and design of
your project . Provide any background information if
necessary .
 Data Design
Global Data Structures: Describe any data structures that are a major part of
this system. This should include major data structures that are passed
between components. That is, it is not restricted to truly global data
structures.
Database Description: Describe the database(s) which is/are part of the
system
dEscRIPTIvE TITLE hELPs REAdER
A descriptive title Logging to application in phone. is much better than
'Logging. Remember that the readers will probably have several documents to
read, and they need to have an idea what kind of document this is.
REQUIREMENTS MATRIX
Provide a cross-reference that traces components and
data structures to the requirements in your SRS document .
Use a tabular format to show which system components
satisfy each of the functional requirements from the SRS. Refer
to the functional requirements by the numbers/codes that you
gave them in the SRS.
 Mapping of Functional requirement to System design
component.
SI.NO Functional Requirements System Design Components

1. The User shall be able to create and login Login

into his account with Login ID and Accepting username & password.
password. Verification Authentication

2. The User shall be able to create Multiple Create tree

Family Trees. Creation of new nodes
Creation of new links

3. The User shall be able to Export the Tree Merge node

(exchange with other family tree). Search for both the nodes
Merge the nodes
Display the tree
4. The User shall be able to Import Tree as a Merge tree
Node (Import a family as a Node to an Search for the node where the tree
existing family). must be linked.
Search for tree.
Merge the tree to the node.
Display the tree.
SI.NO Functional Requirements System Design Components

5. The User shall be able to search any of his Search member

family members with search option. Traverse along the tree
Find for a member

6. The User shall be able to store and view No details mentioned in SDD.
messages. Only in data flow diagram the
information about message is
present in whole document.

7. The User shall be able to set and view Reminder

reminder. Set the reminders
View the reminders
Trigger the reminder

8. The User shall be able to add family photos, No information regarding this
images of records, videos, and more. requirement in SDD
Summary Of DESIGN Critiquing

The proposed system is a mobile application which helps the end users to
maintain their family members information and interests.
By considering our parameters for critique, we found that design
document structure is good according to IEEE template but a missing
System Overview which reduces quality of document.
we found this design document was well researched and written. Minor
errors were noted, but information included was correct, relevant.
There were some cases of incompleteness within mapping of functional
requirement to system components.
However, the SDD were thorough in most areas with their explanations,
and with the aid of Use case, sequence Diagrams, E-R Diagrams, and
Data Diagrams, the document was clear and concise.
Thank you.
Any queries?