Information Systems Analysis and Design csc3402002 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 csc3402002 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 externallySupportingSupporting system testing, verification and validationactivities -- specification should include sufficient informationso that when the system is delivered, it is possible to makesure that it meets requirementsControllingControlling system evolution -- maintenance, extensions andenhancements to system should be consistent withrequirements, else the requirements themselves must evolveInformation Systems Analysis and Design csc3402002 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 interfacesFunctional requirementsFunctional requirements (also called behaviouralbehavioural requirements requirements)specify what the system does by relating inputs to outputsNon-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 overDesignsDesigns -- because inclusion of designs is irrelevant to end-users and customers and pre-empts the design phaseQuality assurance plans Quality assurance plans -- for example, configurationmanagement plans, verification and validation plans, test plans,quality assurance plansInformation Systems Analysis and Design csc3402002 John MylopoulosSoftware Requirements Specification 4Content QualitiesContent QualitiesCorrectCorrect 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 processConsistentConsistent 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 csc3402002 John MylopoulosSoftware Requirements Specification 5Qualities of a Well-Written RSDQualities of a Well-Written RSDUnderstandable 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 csc3402002 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 csc3402002 John MylopoulosSoftware Requirements Specification 7Style QualitiesStyle QualitiesDesign-independentDesign-independent in the sense that it does not imply aparticular software architecture or algorithmAnnotatedAnnotated 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 changeConciseConcise -- the shorter an RSD document the betterOrganizedOrganized in the sense that it is easy to locate any onerequirementInformation Systems Analysis and Design csc3402002 John MylopoulosSoftware Requirements Specification 8There is no Perfect RSD!There is no
View Full Document