DOC PREVIEW
Toronto CSC 340 - The Requirements Specification Document (RSD)

This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Information Systems Analysis and Design csc3402002 John MylopoulosSoftware Requirements Specification 1XIV. The RequirementsXIV. The RequirementsSpecification Document (RSD)Specification Document (RSD)What is a RSD?What is a RSD?What to include/not include in a RSD?What to include/not include in a RSD?Attributes of a Well-Written RSDAttributes of a Well-Written RSDOrganization of a RSDOrganization of a RSDSample Table of ContentsSample Table of ContentsAn Example An Example Information Systems Analysis and Design csc3402002 John MylopoulosSoftware Requirements Specification 2The Requirements SpecificationThe Requirements SpecificationDocumentDocument (RSD) This is the document that is generated by the requirementsengineering process; the document describes all requirementsfor the system under design and is intended for severalpurposes:CommunicationCommunication among customers, users and designers --specification should be quite specific about what the systemwill look like externallySupportingSupporting system testing, verification and validationactivities -- specification should include sufficient informationso that when the system is delivered, it is possible to makesure that it meets requirementsControllingControlling system evolution -- maintenance, extensions andenhancements to system should be consistent withrequirements, else the requirements themselves must evolveInformation Systems Analysis and Design csc3402002 John MylopoulosSoftware Requirements Specification 3Contents of a RSDContents of a RSD What to include in a RSD: A complete yet concise description of the entire externalinterface of the system with its environment, including othersoftware, communication ports, hardware and user interfacesFunctional requirementsFunctional requirements (also called behaviouralbehavioural requirements requirements)specify what the system does by relating inputs to outputsNon-Functional requirements Non-Functional requirements (also called qualityquality or non-non-behaviouralbehavioural) define the attributes of the system as it operates What notnot to include in a RSD:Project requirements Project requirements -- because these are development-specificand become irrelevant as soon as the project is overDesignsDesigns -- because inclusion of designs is irrelevant to end-users and customers and pre-empts the design phaseQuality assurance plans Quality assurance plans -- for example, configurationmanagement plans, verification and validation plans, test plans,quality assurance plansInformation Systems Analysis and Design csc3402002 John MylopoulosSoftware Requirements Specification 4Content QualitiesContent QualitiesCorrectCorrect in the sense that all stated requirements represent a need astakeholder has (customer, user, analyst or designer)UnambiguousUnambiguous in the sense that every stated requirement has aunique interpretation.CompleteComplete in the sense that it possesses the following four qualities: Everything the software is supposed to do is in the RSD; The response to all possible input combinations is stated explicitly; Pages and figures are numbered (document completeness); There are no “to-be-determined” sections in the document.VerifiableVerifiable in that every requirement can be established through afinite cost, effective processConsistentConsistent in that no requirement is in conflict with existingdocuments or with another stated requirement; incosistencies amongrequirements may be of four kinds (i) conflicting behaviour, (ii)conflicting terms, (iii) conflicting attributes (iv) temporal inconsistenciesInformation Systems Analysis and Design csc3402002 John MylopoulosSoftware Requirements Specification 5Qualities of a Well-Written RSDQualities of a Well-Written RSDUnderstandable by customersUnderstandable by customers, which means that formal notationscan only be used as backup to help with consistency and precision,while the RSD document itself is expressed in natural language orsome notation the customer is familiar with (e.g., UML.)ModifiableModifiable in the sense that it can be easily changed withoutaffecting completeness, consistency; modifiability is enhanced by atable of contents (TOC), an index and cross references whereappropriate; redundancy can also be used (mention the samerequirement several times, but cross-reference them all)TracedTraced in that the origin of every requirement is clear; this can beachieved by referencing earlier documents (pre-existing documents,drafts, memos,...)TraceableTraceable in the sense that attributes of the design can be tracedback to requirements and vice versa; also, during testing you want toknow which requirement is being tested by which test batch; toenhance traceability (i) number every requirement, (ii) number everypart of the RSD hierarchically, all the way down to paragraphsInformation Systems Analysis and Design csc3402002 John MylopoulosSoftware Requirements Specification 6TraceableTraceable vs vs Traced TracedSystem-level Reqsdrafts, memos,...System-levelSystem-level Reqs Reqsdrafts, memos,...drafts, memos,...Software RequirementsSpecificationSoftware RequirementsSoftware RequirementsSpecificationSpecification Software Design Software Software DesignDesigntracedtracedtraceabletraceabletraceabletraceableInformation Systems Analysis and Design csc3402002 John MylopoulosSoftware Requirements Specification 7Style QualitiesStyle QualitiesDesign-independentDesign-independent in the sense that it does not imply aparticular software architecture or algorithmAnnotatedAnnotated in that it provides guidance to the developers; twouseful types of annotations are (i) relative neccesity, i.e., hownecessary is a particular requirement from a stakeholderperspective, (ii) relative stability, i.e., how likely is it that arequirement will changeConciseConcise -- the shorter an RSD document the betterOrganizedOrganized in the sense that it is easy to locate any onerequirementInformation Systems Analysis and Design csc3402002 John MylopoulosSoftware Requirements Specification 8There is no Perfect RSD!There is no


View Full Document

Toronto CSC 340 - The Requirements Specification Document (RSD)

Documents in this Course
Scoping

Scoping

10 pages

Load more
Download The Requirements Specification Document (RSD)
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view The Requirements Specification Document (RSD) and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view The Requirements Specification Document (RSD) 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?