CSEB274RequirementsEngineering
Semester2,2018/2019
Assignment/Project:PartII
Weightage:20%
TasksandDeliverables:
• Elicitexistingrequirementsbyobserving,analysingandtryingtheInstituteofAdvancedTechnology
websiteherehttp://www.itma.upm.edu.my/?L=enandsuggestseveralnewdelighterstooforthe
websiteoftheInstituteofEnergyInfrastructure(IEI).
a. Preparethesoftwarerequirementsspecifications(SRS)documentoftheselectedsystem
basedonthegiventemplate(seeSRS–Template–BCS(SE)2018v1.1.docx)
b. ThetemplatewascreatedbasedonISO/IEC/IEEE29148:2011standard,IEEEStd830-1998
andSRSTemplatecreatedbyKarlWiegers.Refertothesestandardsfordetaileddescription
oftheitemsintheoutline.AppendixAprovidesexcerptsfromtheISO/IEC/IEEE29148:2011
standard.
c. Usebelowtemplatetospecifythefunctionalrequirementsofthesystem(referL-19&L-20:
CoreActivities–Documentation):
RulesandRequirements:
1. Thisisagroupassignment/project(bestinthesamegroupasinAssignment1).
2. This assignment/project is a mandatory course assessment and to be graded, that shall be solved
andreportedtogetherwithyourgroupmembers.
3. Individualcontributiontotheproject:
• Aftertheprojectendsyouwillbeaskedtoevaluateyourownaswellasyourpeers’contribution
totheresultandtheoverallworkingofthegroup.Thiscanbeusedasonebasisforthegrading
ofanindividual.Itisveryimportantthateverygroupmembercontributescontinuouslytothe
projectandgroup.
4. Othermandatoryrequirements:
• Proper and complete references to all supporting books/papers/info! Use referencing styles
explainedintheReportWritingGuidelineavailablefromhttp://sephiroth/spmsv2/
• Textformatting:Calibri(notmorethan11points),single-spacing,justifyparagraph
• PlagiarismwillyieldanimmediateFAIL(zeroscore)ontheproject,whichwillbecheckedusing
theTurnitinsoftware.
• Clearly state the group name and IDs, names of the members and name of the system in the
SRS.
• Bindthedocumentneatlybutavoidusingring-bindandplasticcover.
• Submityourdocumentationbythegivendeadline.
•
•
Deadline: 9th Jan 2019 (12:00 noon) – deadline means, you will be ‘dead’ if you submit your
documentationlaterthanthespecifieddateandtime.
AddthefollowingdeclarationpagetotheAppendixoftheSRS.Modifytheformtoincludeall
thenamesofthegroupmembers.
Weherebydeclarethatthisassignmentistheresultofourownwork.Nopartoftheprogram
hasbeencopied/alteredfromotherstudent(s)orbyotherstudent(s)orfromothersources
suchasbooks,Internet,etc.
Signature:_____________________
Signature:_____________________
Name :WriteyourIDandnamehereName:WriteyourIDandnamehere
Date
:Writesubmissiondatehere
APPENDIXA:EXCERPTFROMISO/IEC/IEEE29148:2011
ISO/IEC/IEEE 29148:2011(E)
NOTE 1
Verification, Section 4 in Figure 8, is not included in the original IEEE Std. 830.
Examples of organizational approaches to requirements in an SRS include:
System mode - Some systems behave quite differently depending on the mode of operation. For example, a
control system may have different sets of functions depending on its mode: training, normal, or emergency.
User class - Some systems provide different sets of functions to different classes of users. For example, an
elevator control system presents different capabilities to passengers, maintenance workers, and firefighters.
Objects - Objects are real-world entities that have a counterpart within the system. For example, in a patient
monitoring system, objects include patients, sensors, nurses, rooms, physicians, medicines, etc. Associated
with each object is a set of attributes (of that object) and functions (performed by that object). These functions
are also called services, methods, or processes.
Feature - A feature is an externally desired service by the system that may require a sequence of inputs to
effect the desired result. For example, in a telephone system, features include local call, call forwarding, and
conference call. Each feature is generally described in a sequence of stimulus-response pairs.
Stimulus - Some systems can be best organized by describing their functions in terms of stimuli. For example,
the functions of an automatic aircraft landing system may be organized into sections for loss of power, wind
shear, sudden change in roll, vertical velocity excessive, etc.
Response - Some systems can be best organized by describing all the functions in support of the generation
of a response. For example, the functions of a personnel system may be organized into sections
corresponding to all functions associated with generating paychecks, all functions associated with generating
a current list of employees, etc.
Functional hierarchy - When none of the above organizational schemes prove helpful, the overall functionality
can be organized into a hierarchy of functions organized by common inputs, common outputs, or common
internal data access. Data flow diagrams and data dictionaries can be used to show the relationships between
and among the functions and data.
NOTE 2
There are many notations, methods, and automated support tools available to aid in the documentation of
SRS requirements. For the most part, their usefulness is a function of organization. For example, when organizing by
mode, finite state machines or state charts may prove helpful; when organizing by object, object-oriented analysis may
prove helpful; when organizing by feature, stimulus-response sequences may prove helpful; and when organizing by
functional hierarchy, data flow diagrams and data dictionaries may prove helpful.
9
Information item content
9.1
Introduction
This clause states the normative content of the required information items. The content for the software
requirements specification document, as stated in subclause 9.5, is only applicable if adhering to System
Requirements Analysis Process of ISO/IEC 12207.
NOTE
form.
9.2
9.2.1
Information content in subclause 9.2 is generally applicable to items of information maintained in document
General content
Identification
Include the following identification matter:
a) Title
46
© ISO/IEC 2011 – All rights reserved
© IEEE 2011 – All rights reserved
ISO/IEC/IEEE 29148:2011(E)
b) Revision notice
The title and a revision notice uniquely identify the document. Revision information may include the project
name, version number of the document, date of release, approved signature, a list of subclauses that have
been changed in the current version of the document, and a list of version numbers and dates of release of all
previous versions of the document.
9.2.2
Front matter
Include the following front matter:
a) A table of contents
b) A list of figures
c) A list of tables
9.2.3
Definitions
Provide definitions for any words or phrases that have special meaning beyond normal dictionary definitions.
9.2.4
References
Include the following information regarding references:
a) Provide a complete list of all documents referenced elsewhere;
b) Identify each document by title, report number (if applicable), date and publishing organization;
c) Specify the sources from which the references can be obtained.
This information may be provided by reference to an appendix or to another document. The references
information should be subdivided into a 'Compliance' section, containing references to those cited documents
containing requirements which are included by that citation and a ‘Guidance' section, containing reference to
those cited documents containing information, but no requirements.
9.2.5
Acronyms and abbreviations
Spell out or define all acronyms and abbreviations used in the documents.
NOTE
This information may be provided by reference to one or more appendixes in the documents or by reference to
other documents.
9.3 Stakeholder requirements specification (StRS) document
This clause defines the normative content of the stakeholder requirements specification (StRS) document. The
project shall produce the following information items in accordance with the project's policies with respect to
the stakeholder requirements specification document. Organization of the information items in the document
such as the order and section structure may be selected in accordance with the project's documentation
policies.
9.3.1
Business purpose
Describe at the organization level the reason and background for which the organization is pursuing new
business or changing the current business in order to fit a new management environment. In this context it
should describe how the proposed system will contribute to meeting business objectives.
© ISO/IEC 2011 – All rights reserved
© IEEE 2011 – All rights reserved
47