Final Year Project

Documentation
Assignment Description

Software Requirement
Specification

Software Design
Description
 Part One
Assignment Description

2/4/2023 Software Component Design (SENG 4093) 3

Assignment Description you should provide an overview of the entire project or
system what you have done
Introduction In this document you also identifying the problems of th
system that you want to be solve for. The problem is bein
1.1 Problem Definition clearly with respect to environmental, internal and extern
individual.
1.2 Objective
Objectives are the measurable outcomes of t
objectives must be tangible, specific, concrete, measura
1.3 Vision to Problem Definition specified time period.

1.4 Significant of the System After delivering and implementing of thi

system of the organization you should de
improved.
1.5 Target Beneficiaries of the System
Put the general and specific significance
1.6 Planning accomplishment of the system.

Who are beneficial and what? S

answered in this section.
define each major task, estimate the time an
required, and provide a framework for mana
 Part Two
Software Requirement
Specification

2/4/2023 Software Component Design (SENG 4093) 5

 Definition
Software of SRS Specification
Requirement
Software Requirement Specification (SRS) is a
document that completely describe what the
proposed Software should do without describing how
software will do it.
It contains
Complete information descriptions
Detail functional descriptions
Representation of system behavior
An indication of performance requirement and design
constraint
Appropriate validation criteria

Requirements 6
 Definition
Software of SRS Specification
Requirement
Software Requirement Specification (SRS) is a
document that completely describe what the
proposed Software should do without describing how
software will do it.
It contains
Complete information descriptions
Detail functional descriptions
Representation of system behavior
An indication of performance requirement and design
constraint
Appropriate validation criteria

Requirements 7
 Definition
Software of SRS Specification
Requirement
Software Requirement Specification (SRS) is a
document that completely describe what the
proposed Software should do without describing how
software will do it.
It contains
Complete information descriptions
Detail functional descriptions
Representation of system behavior
An indication of performance requirement and design
constraint
Appropriate validation criteria

Requirements 8
Characteristics of an SRS
Correct
Complete
Unambiguous
Consistent
Verifiable
Traceable
Modifiable
Ranked for importance and/or stability

Requirements 9
Characteristics of an SRS
Correctness
Each requirement accurately represents some desired
feature in the final system.
Specifies every true requirement known at that time and
no incorrect specifications - no wrong data
Completeness
All desired features/characteristics specified included
behavior (methods, use cases, systems, subsystems,
business rules) and data (objects, attributes……
Completeness and correctness strongly related
Unambiguous
Each req has exactly one meaning
Without this errors will creep in
Important as natural languages often used
Requirements 10
 Characteristics…
Characteristics of an SRS
Verifiability
 It is the software built what was specified in the SRS
Consistent
 two requirements don’t contradict each other
 No conflicting terms, characteristics.
Traceable
 The origin of the req, and how the req relates to software elements can
be determined
Ranked for importance/stability
 Needed for prioritizing in construction
 To reduce risks due to changing requirements
Modifiable: changing requirements easily modified when specifying, designing,
coding, implementing

Understandable: question:
are formal specifications
understandable, are informal specifications understandable
Requirements 11
Structure of an SRS

This standardization
of the SRS was done
by IEEE.

Requirements 12
 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

Structure ofStandard
IEEE 830-1998 an SRSSection 1 of SRS
1. Introduction •Describe purpose of this SRS
•Describe intended audience

1.1 Purpose •Identify the software product

1.2 Scope
•Enumerate what the system will and will not do
•Describe user classes and benefits for each

1.3 Definitions. Acronyms, and Abbreviations

•Define the vocabulary of the SRS
(may reference appendix)

1.4 References •List all referenced documents including sources

1.5 Overview
(e.g., Use Case Model and Problem Statement;
Experts in the field)

Assignmet Description Document.pdf

•Describe the content of the rest of the SRS

•Describe how the SRS is organized
 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

Structure
IEEE 830-1998of an SRS
Standard – Section 2 of SRS
•Present the business case and operational concept of the syste
•Describe how the proposed system fits into the business conte

2. Overall Description •Describe System interfaces, user interfaces, hardware interfa
communication interfaces and Operation

Provide a summary of the major fun

2.1 Product Perspective that the software will perform.

2.2 Product Functions •Describe and justify technical skills and

capabilities of each user class

2.3 User Characteristics •Describe the environment in w

will operate, including the hard
2.4 Operating Environment operating system and versions,

2.5 Constraints
•Describe other constraints that will
e.g., regulatory policies; target platf

2.5 Assumptions and Dependencies

software and protocols, developmen

2.6 Apportion Requirement

 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

Structure of an SRS
IEEE 830-1998 Standard – Section 3 of SRS (1)
Specify software requirements in sufficient detail to enable designers
3. Specific Requirements design a system to satisfy those requirements and testers to verify
requirements State requirements that are externally perceivable by u
3.1 External Interfaces operators, or externally connected systems

Describe external interfaces, user interfaces, hardwar

3.2 Functional Requirements communication interfaces and Operation

3.3 Non Functional Requirements List of functional requirements

System Use case Diagram, Syste
3.4 Logical Database Requirements Description, Class Diagram and
Diagram
3.5 Design Constraints Description of non fu
based on their priori
3.6 Software System Quality Attributes Performance require
requirement, safety r
3.7 Other Requirements time, usability, suppo
ER Digram
4. Appendices
Specify any additional quality characteristi
5. Index product that will be important to either the
the developers. Like reliability, availability, mai
Assignmet Description Document.pdf
portability, reusability, testability
Section I of SRS
I.A Purpose Paragraph form

I.B Scope of the System Paragraph form

Specified
I.C Definitions, Acronyms, and Table form or
Abbreviations bulleted list
I.D References to Supporting Bulleted list
Documents
I.E Overview of rest of SRS Paragraph form
Section II of SRS
II.A Product Perspective Paragraph form

II.B Product Functions Paragraph form

II.C User Characteristics Paragraph form

II.D General Constraints Paragraph form

II.E Assumptions and Paragraph form

Dependencies
 Part Three
Software Design Description

2/4/2023 Software Component Design (SENG 4093) 18

 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

Structure ofStandard
IEEE 830-1998 an SDD Section 1 of SDD
1. Introduction •Describe purpose of this SDD
•Describe intended audience

1.1 Purpose •Identify the software product

1.2 Scope
•Enumerate what the system will and will not do
•Describe user classes and benefits for each

1.3 Definitions. Acronyms, and Abbreviations

•Define the vocabulary of the SDD
(may reference appendix)

1.4 References •List all referenced documents including sources

1.5 Overview
(e.g., Use Case Model and Problem Statement;
Experts in the field)

•Describe the content of the rest of the SDD

•Describe how the SSDD is organized
 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

Structure
IEEE 830-1998of an SDD
Standard – Section 2 of SDD
Select architectural styles/ patterns
2. Architecture Overview and describe how to design the system

2.1 Architectural Styles/Patterns User role and their privi

2.2 Access Control and Security

3. Design Description Information Content

3.1 Design stakeholders and their concerns

3.2 Design views

3.3 Design Language

 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

Structure of an SDD
IEEE 830-1998 Standard – Section 3 of SDD
To elaborate existing and designed types and their
4. Design Viewpoint implementations as classes with instances of types in outlin
design ideas. , Object Diagram and their description should be iden
4.1 Logical Viewpoint classdiagram in design.JPG, object.JPG

describe briefly about the component of the system and the pac
4.2 Dependency Viewpoint of the system and how the system will be deployed. Component
diagram, deployment diagram, package and their description

4.3 Interaction Viewpoint defines strategies for interaction amon

regarding why, where, how, and at wha
4.4 Information Viewpoint occur. Sequence diagram.

4.5 State Dynamic Viewpoint To elaborate the data structur

of the database. Relational d
4.6 Interface Viewpoint dictionary
To describe the state of the
any interaction. State char

to elaborate the user inter

the system. userinterface1.JPG
2/4/2023 22