Information Systems Analysis and Design csc340 This is the document that is generated by the requirements engineering process the document describes all requirements for the system under design and is intended for several purposes Communication among customers users and designers specification should be quite specific about what the system will look like externally Supporting system testing verification and validation activities specification should include sufficient information so that when the system is delivered it is possible to make sure that it meets requirements Controlling system evolution maintenance extensions and enhancements to system should be consistent with requirements else the requirements themselves must evolve What is a RSD What to include not include in a RSD Attributes of a Well Written RSD Organization of a RSD Sample Table of Contents An Example Software Requirements Specification 1 Information Systems Analysis and Design csc340 The Requirements Specification Document RSD XIV The Requirements Specification Document RSD 2002 John Mylopoulos Information Systems Analysis and Design csc340 2002 John Mylopoulos Software Requirements Specification 2 Information Systems Analysis and Design csc340 Contents of a RSD Content Qualities What to include in a RSD A complete yet concise description of the entire external interface of the system with its environment including other software communication ports hardware and user interfaces Functional requirements also called behavioural requirements requirements specify what the system does by relating inputs to outputs Non Functional requirements also called quality or nonbehavioural behavioural define the attributes of the system as it operates What not to include in a RSD Project requirements because these are development specific and become irrelevant as soon as the project is over Designs because inclusion of designs is irrelevant to endusers and customers and pre empts the design phase Quality assurance plans for example configuration management plans verification and validation plans test plans quality assurance plans Correct in the sense that all stated requirements represent a need a stakeholder has customer user analyst or designer Unambiguous in the sense that every stated requirement has a unique interpretation Complete 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 Verifiable in that every requirement can be established through a finite cost effective process Consistent in that no requirement is in conflict with existing documents or with another stated requirement incosistencies among requirements may be of four kinds i conflicting behaviour ii conflicting terms iii conflicting attributes iv temporal inconsistencies 2002 John Mylopoulos Software Requirements Specification 3 Information Systems Analysis and Design csc340 2002 John Mylopoulos Information Systems Analysis and Design Qualities of a Well Written RSD RSD Software Requirements Specification 5 csc340 Traceable vs Traced Understandable by customers customers which means that formal notations can only be used as backup to help with consistency and precision while the RSD document itself is expressed in natural language or some notation the customer is familiar with e g UML Modifiable in the sense that it can be easily changed without affecting completeness consistency modifiability is enhanced by a table of contents TOC an index and cross references where appropriate redundancy can also be used mention the same requirement several times but cross reference them all Traced in that the origin of every requirement is clear this can be achieved by referencing earlier documents pre existing documents drafts memos Traceable in the sense that attributes of the design can be traced back to requirements and vice versa also during testing you want to know which requirement is being tested by which test batch to enhance traceability i number every requirement ii number every part of the RSD hierarchically all the way down to paragraphs 2002 John Mylopoulos Software Requirements Specification 4 System level System levelReqs Reqs drafts drafts memos memos traced Software SoftwareRequirements Requirements Specification Specification traceable traceable Software Software Design Design 2002 John Mylopoulos Software Requirements Specification 6 Information Systems Analysis and Design csc340 Information Systems Analysis and Design csc340 There is no Perfect RSD Style Qualities Design independent in the sense that it does not imply a particular software architecture or algorithm Annotated in that it provides guidance to the developers two useful types of annotations are i relative neccesity i e how necessary is a particular requirement from a stakeholder perspective ii relative stability i e how likely is it that a requirement will change Concise the shorter an RSD document the better Organized in the sense that it is easy to locate any one requirement ambiguous ambiguous lengthen it shorten it shorten it lengthen it redundant redundant inconsistent inconsistent shorten it lengthen it shorten it lengthen it not notunderstandable understandable shorten it lengthen it incomplete incomplete 2002 John Mylopoulos Software Requirements Specification 7 Information Systems Analysis and Design csc340 2002 John Mylopoulos Information Systems Analysis and Design 1 Introduction 1 1 Scope 1 2 Document Overview 1 3 Applicable Documents list of other relevant documents 1 4 Nomenclature definition of terms used in the document There are many RSD standards including US DoD DI MCCR80025A NASA SMAP DID P200 SW IEEE ANSI 830 1984 Organization may be based on different criteria External stimulus or external situation e g for an aircraft landing system external stimuli or situations might be wind gusts no fuel System feature e g call forward call long distance System response e g generate pay cheques External object e g by book type for a library information system User type It is useful to define a hierarchy among these criteria use it throughout the RSD document e g sections are defined with respect to wrt external stimulus subsections wrt system feature etc 2 X subsystem name Subsystem X 1 Software Requirements X stands for one or more of 4 5
View Full Document
Unlocking...