| HOLMES INSTITUTE FACULTY OF HIGHER EDUCATION UNDERGRADUATE PROGRAM |
Software Requirements Specification Template
| Assessment Details and Submission Guidelines | |
| Trimester | 2022 |
| Unit Code | HS3052 |
| Unit Title | Capstone Project (Design and Implementation) |
| Assessment Type | Group Assignment |
| Assessment Title | Group Assignment-3: The development and completion of SRS document |
| Purpose of the assessment (with ULO Mapping) |
The team will complete the Software Requirements Specification (SRS) for the information system solution. 1. Apply project planning, technical skills and methods to develop and implement an appropriate solution 2. Apply and evaluate project management skills and concepts in problem solving 3. Present the knowledge, skills and ideas acquired through results and discussion with different audience levels 4. Critically analyse and synthesise complex information into a business proposal 8. Understand the ICT profession and professional expectations in the researched topic |
| Weight | 35% of the total assessments |
| Total Marks | 35 |
| Word limit | 2000 – 2500 |
| Due Date | Week 6 Friday 5pm. |
| Submission Guidelines |
• All work must be submitted on Blackboard by the due date along with a completed Assignment Cover Page. • The assignment must be in MS Word format, no spacing, 11-pt Times New Roman font and 2 cm margins on all four sides of your page with appropriate section headings. • Reference sources must be cited in the text of the report, and listed appropriately at the end in a reference list using Harvard style. |
AssignmentTutorOnline
| HOLMES INSTITUTE FACULTY OF HIGHER EDUCATION UNDERGRADUATE PROGRAM |
Software Requirements Specification Template
Software Requirements Specification Template
HS3052 Information Systems Capstone Project
The following annotated template shall be used to complete the Software Requirements
Specification (SRS) assignment for HS3052 Information Systems Capstone Project.
Template Usage:
Text contained within angle brackets (‘<’, ‘>’) shall be replaced by your project-specific
information and/or details. For example,
Mobile or ‘Business Network’.
Italicized text is included to briefly annotate the purpose of each section within this template.
This text should not appear in the final version of your submitted SRS.
This cover page is not a part of the final template and should be removed before your SRS is
submitted.
Sections of this document are based upon the IEEE Guide to Software Requirements
Software Requirements Specification
Software Requirements Specification Page ii
1. INTRODUCTION……………………………………………………………………………………………………………………………….. 1
1.1 PURPOSE…………………………………………………………………………………………………………………………………………….1
1.2 SCOPE………………………………………………………………………………………………………………………………………………..1
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ………………………………………………………………………………………………1
1.4 REFERENCES…………………………………………………………………………………………………………………………………………1
1.5 OVERVIEW…………………………………………………………………………………………………………………………………………..2
2. GENERAL DESCRIPTION…………………………………………………………………………………………………………………….. 2
2.1 PRODUCT PERSPECTIVE ……………………………………………………………………………………………………………………………2
2.2 PRODUCT FUNCTIONS ……………………………………………………………………………………………………………………………..2
2.3 USER CHARACTERISTICS……………………………………………………………………………………………………………………………2
2.4 GENERAL CONSTRAINTS …………………………………………………………………………………………………………………………..2
2.5 ASSUMPTIONS AND DEPENDENCIES ……………………………………………………………………………………………………………..2
3. SPECIFIC REQUIREMENTS………………………………………………………………………………………………………………….. 3
3.1 EXTERNAL INTERFACE REQUIREMENTS…………………………………………………………………………………………………………..3
3.1.1 User Interfaces …………………………………………………………………………………………………………………………..3
3.1.2 Hardware Interfaces……………………………………………………………………………………………………………………3
3.1.3 Software Interfaces …………………………………………………………………………………………………………………….3
3.1.4 Communications Interfaces………………………………………………………………………………………………………….3
3.2 FUNCTIONAL REQUIREMENTS …………………………………………………………………………………………………………………….3
3.2.1
3.2.2
3.3.1 Use Case #1 ……………………………………………………………………………………………………………………………….4
3.3.2 Use Case #2 ……………………………………………………………………………………………………………………………….4
3.4 CLASSES / OBJECTS…………………………………………………………………………………………………………………………………4
3.4.1
3.4.2
3.5.1 Performance………………………………………………………………………………………………………………………………4
3.5.2 Reliability…………………………………………………………………………………………………………………………………..4
3.5.3 Availability…………………………………………………………………………………………………………………………………4
3.5.4 Security……………………………………………………………………………………………………………………………………..4
3.5.5 Maintainability…………………………………………………………………………………………………………………………..4
3.5.6 Portability………………………………………………………………………………………………………………………………….4
3.6 INVERSE REQUIREMENTS ………………………………………………………………………………………………………………………….4
3.7 DESIGN CONSTRAINTS……………………………………………………………………………………………………………………………..4
3.8 LOGICAL DATABASE REQUIREMENTS …………………………………………………………………………………………………………….4
3.9 OTHER REQUIREMENTS ……………………………………………………………………………………………………………………………5
4. ANALYSIS MODELS…………………………………………………………………………………………………………………………… 5
4.1 SEQUENCE DIAGRAMS……………………………………………………………………………………………………………………………..5
4.3 DATA FLOW DIAGRAMS (DFD)…………………………………………………………………………………………………………………..5
4.2 STATE-TRANSITION DIAGRAMS (STD)…………………………………………………………………………………………………………..5
5. CHANGE MANAGEMENT PROCESS ……………………………………………………………………………………………………… 5
A. APPENDICES …………………………………………………………………………………………………………………………………… 5
Software Requirements Specification Page iii
A.2 APPENDIX 2…………………………………………………………………………………………………………………………………………5
Software Requirements Specification Page 1
The introduction to the Software Requirement Specification (SRS) document should provide an
overview of the complete SRS document. While writing this document please remember that
this document should contain all of the information needed by a software engineer to
adequately design and implement the software product described by the requirements listed in
this document. (Note: the following subsection annotates are largely taken from the IEEE Guide
to SRS).
1.1 Purpose
What is the purpose of this SRS and the (intended) audience for which it is written?
1.2 Scope
This subsection should:
(1) Identify the software product(s) to be produced by name; for example, Host DBMS, Report
Generator, etc
(2) Explain what the software product(s) will, and, if necessary, will not do
(3) Describe the application of the software being specified. As a portion of this, it should:
(a) Describe all relevant benefits, objectives, and goals as precisely as possible. For example,
to say that one goal is to provide effective reporting capabilities is not as good as saying
parameter-driven, user-definable reports with a 2 h turnaround and on-line entry of user
parameters.
(b) Be consistent with similar statements in higher-level specifications (for example, the
System Requirement Specification) , if they exist.What is the scope of this software
product.
1.3 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
appendixes in the SRS or by reference to other documents.
1.4 References
This subsection should:
(1) Provide a complete list of all documents referenced elsewhere in the SRS, or in a separate,
specified document.
(2) Identify each document by title, report number – if applicable – date, and publishing
organization.
(3) Specify the sources from which the references can be obtained.
This information may be provided by reference to an appendix or to another document.
Software Requirements Specification Page 2
This subsection should:
(1) Describe what the rest of the SRS contains
(2) Explain how the SRS is organized.
2. General Description
This section of the SRS should describe the general factors that affect ‘the product and its
requirements. It should be made clear that this section does not state specific requirements; it
only makes those requirements easier to understand.
2.1 Product Perspective
This subsection of the SRS puts the product into perspective with other related products or
projects. (See the IEEE Guide to SRS for more details).
2.2 Product Functions
This subsection of the SRS should provide a summary of the functions that the software will
perform.
2.3 User Characteristics
This subsection of the SRS should describe those general characteristics of the eventual users of
the product that will affect the specific requirements. (See the IEEE Guide to SRS for more
details).
2.4 General Constraints
This subsection of the SRS should provide a general description of any other items that will
limit the developer’s options for designing the system. (See the IEEE Guide to SRS for a partial
list of possible general constraints).
2.5 Assumptions and Dependencies
This subsection of the SRS should list each of the factors that affect the requirements stated in
the SRS. These factors are not design constraints on the software but are, rather, any changes to
them that can affect the requirements in the SRS. For example, an assumption might be that a
specific operating system will be available on the hardware designated for the software
product. If, in fact, the operating system is not available, the SRS would then have to change
accordingly.
Software Requirements Specification Page 3
This will be the largest and most important section of the SRS. The customer requirements will
be embodied within Section 2, but this section will give the D-requirements that are used to
guide the project’s software design, implementation, and testing.
Each requirement in this section should be:
• Correct
• Traceable (both forward and backward to prior/future artifacts)
• Unambiguous
• Verifiable (i.e., testable)
• Prioritized (with respect to importance and/or stability)
• Complete
• Consistent
• Uniquely identifiable (usually via numbering like 3.4.5.6)
Attention should be paid to the carefuly organize the requirements presented in this section so
that they may easily accessed and understood. Furthermore, this SRS is not the software design
document, therefore one should avoid the tendency to over-constrain (and therefore design) the
software project within this SRS.
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2 Functional Requirements
This section describes specific features of the software project. If desired, some requirements
may be specified in the use-case format and listed in the Use Cases Section.
3.2.1
3.2.1.2 Inputs
3.2.1.3 Processing
3.2.1.4 Outputs
3.2.1.5 Error Handling
3.2.2
Software Requirements Specification Page 4
3.3.1 Use Case #1
3.3.2 Use Case #2
…
3.4 Classes / Objects
3.4.1
3.4.1.2 Functions
3.5 Non-Functional Requirements
Non-functional requirements may exist for the following attributes. Often these requirements
must be achieved at a system-wide level rather than at a unit level. State the requirements in
the following sections in measurable terms (e.g., 95% of transaction shall be processed in less
than a second, system downtime may not exceed 1 minute per day, > 30 day MTBF value, etc).
3.5.1 Performance
3.5.2 Reliability
3.5.3 Availability
3.5.4 Security
3.5.5 Maintainability
3.5.6 Portability
3.6 Inverse Requirements
State any *useful* inverse requirements.
3.7 Design Constraints
Specify design constrains imposed by other standards, company policies, hardware limitation,
etc. that will impact this software project.
3.8 Logical Database Requirements
Will a database be used? If so, what logical requirements exist for data formats, storage
capabilities, data retention, data integrity, etc.
Software Requirements Specification Page 5
Catchall section for any additional requirements.
4. Analysis Models
List all analysis models used in developing specific requirements previously given in this SRS.
Each model should include an introduction and a narrative description. Furthermore, each
model should be traceable the SRS’s requirements.
4.1 Sequence Diagrams
4.3 Data Flow Diagrams (DFD)
4.2 State-Transition Diagrams (STD)
5. Change Management Process
Identify and describe the process that will be used to update the SRS, as needed, when project
scope or requirements change. Who can submit changes and by what means, and how will
these changes be approved.
A. Appendices
Appendices may be used to provide additional (and hopefully helpful) information. If present,
the SRS should explicitly state whether the information contained within an appendix is to be
considered as a part of the SRS’s overall set of requirements.
Example Appendices could include (initial) conceptual documents for the software project,
marketing materials, minutes of meetings with the customer(s), etc.
A.1 Appendix 1
A.2 Appendix 2
Software Requirements Specification Page 6
Your submission document should be a single word or pdf document containing your report.
All submissions are to be submitted through the safeAssign facility in Blackboard. Submission
boxes linked to SafeAssign will be set up in the Units Blackboard Shell. Assignments not
submitted through these submission links will not be considered.
Submissions must be made by the due date and time (which will be in the session detailed
above) and determined by your unit coordinator. Submissions made after the due date and
time will be penalized per day late (including weekend days) according to Holmes Institute
policies.
The SafeAssign similarity score will be used in determining the level, if any, of plagiarism.
SafeAssign will check conference web-sites, Journal articles, the Web and your own class
members submissions for plagiarism. You can see your SafeAssign similarity score (or match)
when you submit your assignment to the appropriate drop-box. If this is a concern you will have
a chance to change your assignment and resubmit. However, resubmission is only allowed prior
to the submission due date and time. After the due date and time have elapsed your
assignment will be graded as late. Submitted assignments that indicate a high level of
plagiarism will be penalized according to the Holmes Academic Misconduct policy, there will
be no exceptions. Thus, plan early and submit early to take advantage of the resubmission
feature. You can make multiple submissions, but please remember we only see the last
submission, and the date and time you submitted will be taken from that submission.
Academic Integrity
Holmes Institute is committed to ensuring and upholding Academic Integrity, as Academic
Integrity is integral to maintaining academic quality and the reputation of Holmes’ graduates.
Accordingly, all assessment tasks need to comply with academic integrity guidelines. Table 1
identifies the six categories of Academic Integrity breaches. If you have any questions about
Academic Integrity issues related to your assessment tasks, please consult your lecturer or tutor
for relevant referencing guidelines and support resources. Many of these resources can also be
found through the Study Sills link on Blackboard.
Academic Integrity breaches are a serious offence punishable by penalties that may range from
deduction of marks, failure of the assessment task or unit involved, suspension of course
enrolment, or cancellation of course enrolment.
Software Requirements Specification Page 7
| Plagiarism | Reproducing the work of someone else without attribution. When a student submits their own work on multiple occasions this is known as self-plagiarism. |
| Collusion | Working with one or more other individuals to complete an assignment, in a way that is not authorised. |
| Copying | Reproducing and submitting the work of another student, with or without their knowledge. If a student fails to take reasonable precautions to prevent their own original work from being copied, this may also be considered an offence. |
| Impersonation | Falsely presenting oneself, or engaging someone else to present as oneself, in an in-person examination. |
| Contract cheating | Contracting a third party to complete an assessment task, generally in exchange for money or other manner of payment. |
| Data fabrication and falsification |
Manipulating or inventing data with the intent of supporting false conclusions, including manipulating images. |
Source: INQAAHE, 2020
- Assignment status: Already Solved By Our Experts
- (USA, AUS, UK & CA PhD. Writers)
- CLICK HERE TO GET A PROFESSIONAL WRITER TO WORK ON THIS PAPER AND OTHER SIMILAR PAPERS, GET A NON PLAGIARIZED PAPER FROM OUR EXPERTS
