Information Systems Analysis and Design csc3402004 John MylopoulosSoftware Requirements Specification 1XV. The RequirementsXV. The RequirementsSpecification Document (RSD)Specification Document (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 RSDAn Example An Example Information Systems Analysis and Design csc3402004 John MylopoulosSoftware Requirements Specification 2The Requirements SpecificationThe Requirements SpecificationDocumentDocument (RSD) Produced by the requirements engineeringprocess; describes all requirements for the systemunder design and is intended for several purposes:CommunicationCommunication among customers, users anddesigners;Support Support forfor system testing, verification andvalidation activities;ControlControl of system evolution -- maintenance,extensions and enhancements to system should beconsistent with requirements.Information Systems Analysis and Design csc3402004 John MylopoulosSoftware Requirements Specification 3Contents of a RSDContents of a RSD What to include in a RSD:A complete yet concise description of the entireexternal interface of the system with its environment;Functional Functional (or behaviouralbehavioural) requirements requirements specifywhat the system does by relating inputs to outputs;Non-Functional Non-Functional (qualityquality) requirements requirements prescribeglobal attributes of the system. What notnot to include in a RSD:Project requirementsProject requirements -- they are development-specific, and irrelevant as soon as the project is over.DesignsDesigns -- design is irrelevant to customers.Quality assurance plansQuality assurance plans -- e.g., plans forconfiguration management, verification and validation,testing, etc.Information Systems Analysis and Design csc3402004 John MylopoulosSoftware Requirements Specification 4Content QualitiesContent QualitiesCorrectCorrect in that all stated requirements represent a need astakeholder has (customer, user, analyst or designer,…)UnambiguousUnambiguous in that every stated requirement has aunique interpretation.CompleteComplete in that it possesses the following four qualities:Describes everything the software is supposed to do;The response to input combinations is stated explicitly;Pages and figures are numbered;There are no “to-be-determined” sections.VerifiableVerifiable in that every requirement can be establishedthrough a finite-cost, effective process.ConsistentConsistent in that it avoids (i) conflicting behaviour, (ii)conflicting terms, (iii) conflicting attributes (iv) temporalinconsistenciesInformation Systems Analysis and Design csc3402004 John MylopoulosSoftware Requirements Specification 5Qualities of a Well-Written RSDQualities of a Well-Written RSDUnderstandable by customersUnderstandable by customers, so formal notations canonly be used as backup, while the RSD document itself isexpressed in natural language or perhaps UML.ModifiableModifiable in that it can be easily changed withoutaffecting completeness, consistency; a table of contents(TOC) helps, so does an index and cross referenceswhere appropriate.TracedTraced in that the origin of every requirement is clear;this can be achieved by referencing earlier documents.TraceableTraceable in that attributes of the design can be tracedback to requirements and vice versa; to enhancetraceability (i) number every requirement, (ii) numberevery part of the RSD hierarchically, all the way down toparagraphsInformation Systems Analysis and Design csc3402004 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 DesignDesigntracedtracedtraceabletraceable traceabletraceableInformation Systems Analysis and Design csc3402004 John MylopoulosSoftware Requirements Specification 7Style QualitiesStyle QualitiesDesign-independentDesign-independent in the sense that it does notimply a particular software architecture or algorithmAnnotatedAnnotated in that it provides guidance to thedevelopers; two useful types of annotations are (i)relative necessity, i.e., how necessary is aparticular requirement from a stakeholderperspective, (ii) relative stability, i.e., how likely is itthat a requirement will change.ConciseConcise -- the shorter the better!OrganizedOrganized in the sense that it is easy to locate anyone requirement.Information Systems Analysis and Design csc3402004 John MylopoulosSoftware Requirements Specification 8There is no Perfect RSD!There is no Perfect RSD!incompleteincompleteincompletenot understandablenot understandablenot understandableambiguousambiguousambiguousredundantredundantredundantinconsistentinconsistentinconsistentshorten it!lengthen it!shorten it!shorten it!lengthen it!shorten it!lengthen it!lengthen it!shorten it!lengthen it!Information Systems Analysis and Design csc3402004 John MylopoulosSoftware Requirements Specification 9How to Organize a RSDHow to Organize a RSD There are many RSD standards, including: US DoDDI-MCCR-80025A, IEEE ANSI 830-1984, etc. Organization may be based on different criteria:External stimulus or external situation, e.g., for anaircraft landing system, wind gusts, no fuel,...;System feature, e.g., call forward,...;System response, e.g., generate pay-cheques;External object, e.g., by book type for a library;User type/use case. It is useful to define a hierarchy among these criteria,use it throughout the RSD document, e.g., sectionsare defined with respect to (wrt) external stimulus,subsections wrt system feature etc.Information Systems Analysis and Design csc3402004 John MylopoulosSoftware Requirements Specification 10Example System DecompositionExample System DecompositionAn Automated Money Machine (AMM) might bedecomposed as follows:Banking ApplicationsBanking Applications handles banking transactions.Network ManagerNetwork
View Full Document
Unlocking...