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 [Link]
•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 [Link]
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 [Link], [Link]
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. [Link]
2/4/2023 22
