HOLMESINSTITUTEFACULTY OFHIGHEREDUCATIONUNDERGRADUATEPROGRAM Software Requirements Specification Template Assessment Details and Submission GuidelinesTrimesterT1 2021Unit CodeHS3052Unit TitleCapstone Project (Design and Implementation)Assessment TypeGroup AssignmentAssessment TitleGroup Assignment-3: The development and completion of SRS documentPurpose of theassessment (withULO Mapping)The team will complete the Software Requirements Specification (SRS) for theinformation system solution.1. Apply project planning, technical skills and methods to develop andimplement an appropriate solution2. Apply and evaluate project management skills and concepts in problemsolving3. Present the knowledge, skills and ideas acquired through results anddiscussion with different audience levels4. Critically analyse and synthesise complex information into a businessproposal8. Understand the ICT profession and professional expectations in theresearched topicWeight35% of the total assessmentsTotal Marks35Word limit2000 – 2500Due DateWeek 6 Friday 5pm.SubmissionGuidelines• All work must be submitted on Blackboard by the due date along with a completedAssignment Cover Page.• The assignment must be in MS Word format, no spacing, 11-pt Times New Romanfont and 2 cm margins on all four sides of your page with appropriate sectionheadings.• Reference sources must be cited in the text of the report, and listed appropriatelyat the end in a reference list using Harvard style. HOLMESINSTITUTEFACULTY OFHIGHEREDUCATIONUNDERGRADUATEPROGRAM Software Requirements Specification TemplateAssessment Design – Adapted Harvard Referencing:Holmes will be implementing as a pilot program a revised Harvard approach to referencing. Thefollowing guidelines apply:1. Reference sources in assignments are limited to sources which provide full text access tothe source’s content for lecturers and markers.2. The Reference list should be located on a separate page at the end of the essay andtitled: References.3. It should include the details of all the in-text citations, arranged alphabetically A-Z byauthor surname. In addition, it MUST include a hyperlink to the full text of the citedreference source.For example;P Hawking, B McCarthy, A Stein (2004), Second Wave ERP Education, Journal ofInformation Systems Education, Fall, http://jise.org/Volume15/n3/JISEv15n3p327.pdf4. All assignments will require additional in-text reference details which will consist of thesurname of the author/authors or name of the authoring body, year of publication, pagenumber of contents, paragraph where the content can be found.For example;“The company decided to implement a enterprise wide data warehouse businessintelligence strategies (Hawking et al, 2004, p3(4)).”Non-Adherence to Referencing GuidelinesWhere students do not follow the above guidelines:1. Students who submit assignments which do not comply with the guidelines will beasked to resubmit their assignments.2. Late penalties will apply, as per the Student Handbook each day, after the student/shave been notified of the resubmission requirements.3. Students who comply with guidelines and the citations are “fake” will be reported foracademic misconduct. HOLMESINSTITUTEFACULTY OFHIGHEREDUCATIONUNDERGRADUATEPROGRAM Software Requirements Specification TemplateSoftware Requirements Specification TemplateHS3052 Information Systems Capstone ProjectThe following annotated template shall be used to complete the Software RequirementsSpecification (SRS) assignment for HS3052 Information Systems Capstone Project.Template Usage:Text contained within angle brackets (‘’) shall be replaced by your project-specificinformation and/or details. For example, will be replaced with either ‘SmartMobile 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 issubmitted.Acknowledgements:Sections of this document are based upon the IEEE Guide to Software RequirementsSoftware Requirements SpecificationSoftware Requirements Specification Page iiTable of Contents1. INTRODUCTION……………………………………………………………………………………………………………………………….. 11.1 PURPOSE…………………………………………………………………………………………………………………………………………….11.2 SCOPE………………………………………………………………………………………………………………………………………………..11.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ………………………………………………………………………………………………11.4 REFERENCES…………………………………………………………………………………………………………………………………………11.5 OVERVIEW…………………………………………………………………………………………………………………………………………..22. GENERAL DESCRIPTION…………………………………………………………………………………………………………………….. 22.1 PRODUCT PERSPECTIVE ……………………………………………………………………………………………………………………………22.2 PRODUCT FUNCTIONS ……………………………………………………………………………………………………………………………..22.3 USER CHARACTERISTICS……………………………………………………………………………………………………………………………22.4 GENERAL CONSTRAINTS …………………………………………………………………………………………………………………………..22.5 ASSUMPTIONS AND DEPENDENCIES ……………………………………………………………………………………………………………..23. SPECIFIC REQUIREMENTS………………………………………………………………………………………………………………….. 33.1 EXTERNAL INTERFACE REQUIREMENTS…………………………………………………………………………………………………………..33.1.1 User Interfaces …………………………………………………………………………………………………………………………..33.1.2 Hardware Interfaces……………………………………………………………………………………………………………………33.1.3 Software Interfaces …………………………………………………………………………………………………………………….33.1.4 Communications Interfaces………………………………………………………………………………………………………….33.2 FUNCTIONAL REQUIREMENTS …………………………………………………………………………………………………………………….33.2.1 ……………………………………………………………………………………….33.2.2 ……………………………………………………………………………………….33.3 USE CASES…………………………………………………………………………………………………………………………………………..43.3.1 Use Case #1 ……………………………………………………………………………………………………………………………….43.3.2 Use Case #2 ……………………………………………………………………………………………………………………………….43.4 CLASSES / OBJECTS…………………………………………………………………………………………………………………………………43.4.1 ……………………………………………………………………………………………………………………..43.4.2 ……………………………………………………………………………………………………………………..43.5 NON-FUNCTIONAL REQUIREMENTS ……………………………………………………………………………………………………………..43.5.1 Performance………………………………………………………………………………………………………………………………43.5.2 Reliability…………………………………………………………………………………………………………………………………..43.5.3 Availability…………………………………………………………………………………………………………………………………43.5.4 Security……………………………………………………………………………………………………………………………………..43.5.5 Maintainability…………………………………………………………………………………………………………………………..43.5.6 Portability………………………………………………………………………………………………………………………………….43.6 INVERSE REQUIREMENTS ………………………………………………………………………………………………………………………….43.7 DESIGN CONSTRAINTS……………………………………………………………………………………………………………………………..43.8 LOGICAL DATABASE REQUIREMENTS …………………………………………………………………………………………………………….43.9 OTHER REQUIREMENTS ……………………………………………………………………………………………………………………………54. ANALYSIS MODELS…………………………………………………………………………………………………………………………… 54.1 SEQUENCE DIAGRAMS……………………………………………………………………………………………………………………………..54.3 DATA FLOW DIAGRAMS (DFD)…………………………………………………………………………………………………………………..54.2 STATE-TRANSITION DIAGRAMS (STD)…………………………………………………………………………………………………………..55. CHANGE MANAGEMENT PROCESS ……………………………………………………………………………………………………… 5A. APPENDICES …………………………………………………………………………………………………………………………………… 5Software Requirements Specification Page iiiA.1 APPENDIX 1…………………………………………………………………………………………………………………………………………5A.2 APPENDIX 2…………………………………………………………………………………………………………………………………………5Software Requirements Specification Page 11. IntroductionThe introduction to the Software Requirement Specification (SRS) document should provide anoverview of the complete SRS document. While writing this document please remember thatthis document should contain all of the information needed by a software engineer toadequately design and implement the software product described by the requirements listed inthis document. (Note: the following subsection annotates are largely taken from the IEEE Guideto SRS).1.1 PurposeWhat is the purpose of this SRS and the (intended) audience for which it is written?1.2 ScopeThis subsection should:(1) Identify the software product(s) to be produced by name; for example, Host DBMS, ReportGenerator, 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 sayingparameter-driven, user-definable reports with a 2 h turnaround and on-line entry of userparameters.(b) Be consistent with similar statements in higher-level specifications (for example, theSystem Requirement Specification) , if they exist.What is the scope of this softwareproduct.1.3 Definitions, Acronyms, and AbbreviationsThis subsection should provide the definitions of all terms, acronyms, and abbreviations requiredto properly interpret the SRS. This information may be provided by reference to one or moreappendixes in the SRS or by reference to other documents.1.4 ReferencesThis 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 publishingorganization.(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 21.5 OverviewThis subsection should:(1) Describe what the rest of the SRS contains(2) Explain how the SRS is organized.2. General DescriptionThis section of the SRS should describe the general factors that affect ‘the product and itsrequirements. It should be made clear that this section does not state specific requirements; itonly makes those requirements easier to understand.2.1 Product PerspectiveThis subsection of the SRS puts the product into perspective with other related products orprojects. (See the IEEE Guide to SRS for more details).2.2 Product FunctionsThis subsection of the SRS should provide a summary of the functions that the software willperform.2.3 User CharacteristicsThis subsection of the SRS should describe those general characteristics of the eventual users ofthe product that will affect the specific requirements. (See the IEEE Guide to SRS for moredetails).2.4 General ConstraintsThis subsection of the SRS should provide a general description of any other items that willlimit the developer’s options for designing the system. (See the IEEE Guide to SRS for a partiallist of possible general constraints).2.5 Assumptions and DependenciesThis subsection of the SRS should list each of the factors that affect the requirements stated inthe SRS. These factors are not design constraints on the software but are, rather, any changes tothem that can affect the requirements in the SRS. For example, an assumption might be that aspecific operating system will be available on the hardware designated for the softwareproduct. If, in fact, the operating system is not available, the SRS would then have to changeaccordingly.Software Requirements Specification Page 33. Specific RequirementsThis will be the largest and most important section of the SRS. The customer requirements willbe embodied within Section 2, but this section will give the D-requirements that are used toguide 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 sothat they may easily accessed and understood. Furthermore, this SRS is not the software designdocument, therefore one should avoid the tendency to over-constrain (and therefore design) thesoftware project within this SRS.3.1 External Interface Requirements3.1.1 User Interfaces3.1.2 Hardware Interfaces3.1.3 Software Interfaces3.1.4 Communications Interfaces3.2 Functional RequirementsThis section describes specific features of the software project. If desired, some requirementsmay be specified in the use-case format and listed in the Use Cases Section.3.2.1 3.2.1.1 Introduction3.2.1.2 Inputs3.2.1.3 Processing3.2.1.4 Outputs3.2.1.5 Error Handling3.2.2 …Software Requirements Specification Page 43.3 Use Cases3.3.1 Use Case #13.3.2 Use Case #2…3.4 Classes / Objects3.4.1 3.4.1.1 Attributes3.4.1.2 Functions3.4.2 …3.5 Non-Functional RequirementsNon-functional requirements may exist for the following attributes. Often these requirementsmust be achieved at a system-wide level rather than at a unit level. State the requirements inthe following sections in measurable terms (e.g., 95% of transaction shall be processed in lessthan a second, system downtime may not exceed 1 minute per day, > 30 day MTBF value, etc).3.5.1 Performance3.5.2 Reliability3.5.3 Availability3.5.4 Security3.5.5 Maintainability3.5.6 Portability3.6 Inverse RequirementsState any *useful* inverse requirements.3.7 Design ConstraintsSpecify design constrains imposed by other standards, company policies, hardware limitation,etc. that will impact this software project.3.8 Logical Database RequirementsWill a database be used? If so, what logical requirements exist for data formats, storagecapabilities, data retention, data integrity, etc.Software Requirements Specification Page 53.9 Other RequirementsCatchall section for any additional requirements.4. Analysis ModelsList all analysis models used in developing specific requirements previously given in this SRS.Each model should include an introduction and a narrative description. Furthermore, eachmodel should be traceable the SRS’s requirements.4.1 Sequence Diagrams4.3 Data Flow Diagrams (DFD)4.2 State-Transition Diagrams (STD)5. Change Management ProcessIdentify and describe the process that will be used to update the SRS, as needed, when projectscope or requirements change. Who can submit changes and by what means, and how willthese changes be approved.A. AppendicesAppendices 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 beconsidered 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 1A.2 Appendix 2Software Requirements Specification Page 6PLEASE NOTEYour 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. Submissionboxes linked to SafeAssign will be set up in the Units Blackboard Shell. Assignments notsubmitted through these submission links will not be considered.Submissions must be made by the due date and time (which will be in the session detailedabove) and determined by your unit coordinator. Submissions made after the due date andtime will be penalized per day late (including weekend days) according to Holmes Institutepolicies.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 classmembers 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 havea chance to change your assignment and resubmit. However, resubmission is only allowed priorto the submission due date and time. After the due date and time have elapsed yourassignment will be graded as late. Submitted assignments that indicate a high level ofplagiarism will be penalized according to the Holmes Academic Misconduct policy, there willbe no exceptions. Thus, plan early and submit early to take advantage of the resubmissionfeature. You can make multiple submissions, but please remember we only see the lastsubmission, and the date and time you submitted will be taken from that submission.Academic IntegrityHolmes Institute is committed to ensuring and upholding Academic Integrity, as AcademicIntegrity is integral to maintaining academic quality and the reputation of Holmes’ graduates.Accordingly, all assessment tasks need to comply with academic integrity guidelines. Table 1identifies the six categories of Academic Integrity breaches. If you have any questions aboutAcademic Integrity issues related to your assessment tasks, please consult your lecturer or tutorfor relevant referencing guidelines and support resources. Many of these resources can also befound through the Study Sills link on Blackboard.Academic Integrity breaches are a serious offence punishable by penalties that may range fromdeduction of marks, failure of the assessment task or unit involved, suspension of courseenrolment, or cancellation of course enrolment.Software Requirements Specification Page 7Table 1: Six categories of Academic Integrity breaches PlagiarismReproducing the work of someone else without attribution.When a student submits their own work on multipleoccasions this is known as self-plagiarism.CollusionWorking with one or more other individuals to complete anassignment, in a way that is not authorised.CopyingReproducing and submitting the work of another student,with or without their knowledge. If a student fails to takereasonable precautions to prevent their own original workfrom being copied, this may also be considered an offence.ImpersonationFalsely presenting oneself, or engaging someone else topresent as oneself, in an in-person examination.Contract cheatingContracting a third party to complete an assessment task,generally in exchange for money or other manner ofpayment.Data fabrication andfalsificationManipulating or inventing data with the intent of supportingfalse conclusions, including manipulating images. Source: INQAAHE, 2020
