University of Toronto But an SRS doesn t need to be a single paper document Choosing an appropriate size and formality Purpose Communicates an understanding of the requirements Desiderata for Specifications explains both the application domain and the system to be developed Properties of good specifications Contractual Typical problems May be legally binding Expresses agreement and a commitment What not to include How do we communicate the Requirements to others It is common practice to capture them in an SRS Why we need to write specifications Purpose and audience Department of Computer Science Software Requirements Specification Lecture 5 Requirements Specifications University of Toronto Department of Computer Science Baseline for evaluating subsequent products Structure of a requirements document supports system testing verification and validation enough information to verify whether delivered system meets requirements IEEE standard Baseline for change control requirements change software evolves 1 Easterbrook 2004 University of Toronto Systems Analysts Requirements Analysts Write various specifications that interrelate Developers Programmers Have to implement the requirements Testers Determine that the requirements have been met Project Managers Measure and control the analysis and development processes Department of Computer Science A complication Procurement An SRS may be written by the procurer A Tiny project 1 programmer 2 months work SRS is really a call for proposals Must be general enough to yield a good selection of bids and specific enough to exclude unreasonable bids programmer talks to customer then writes up a 5 page memo B Large project 50 programmers 2 years work the bidders team of analysts model the requirements then document them in a 500 page SRS Easterbrook 2004 Most interested in system requirements Not generally interested in detailed software requirements 2 University of Toronto Department of Computer Science Consider two different projects Project A Crystalizes programmer s Purpose of spec understanding feedback to customer Spec is irrelevant have Management already allocated view resources Primary Spec author Readers Secondary Customer Users Purchasers Easterbrook 2004 Appropriate Specification Audience SRS is a proposal to implement a system to meet the CfP must be specific enough to demonstrate feasibility and technical competence and general enough to avoid over commitment Project B Build to document must contain enough detail for all the programmers Will use the spec to estimate resource needs and plan the development Primary programmers testers managers Secondary customers the selected developer reflects the developer s understanding of the customers needs forms the basis for evaluation of contractual performance or by an independent RE contractor Choice over what point to compete the contract Early conceptual stage can only evaluate bids on apparent competence ability Late detailed specification stage more work for procurer appropriate RE expertise may not be available in house IEEE Standard recommends SRS jointly developed by procurer developer 3 Easterbrook 2004 4 1 University of Toronto University of Toronto Department of Computer Science Desiderata for Specifications Department of Computer Science There is no Perfect SRS Source Adapted from IEEE STD 830 1998 Valid or correct Expresses only the real needs of the stakeholders customers users Doesn t contain anything that isn t required I e is satisfiable Conceptual Completeness resolve add explanations Modifiable not not understandable understandable Good structure and cross referencing Understandable Clear E g by non computer specialists incomplete incomplete Traceable etc Origin of each requirement is clear Facilitates referencing of requirements in future documentation 5 Easterbrook 2004 University of Toronto 6 Easterbrook 2004 University of Toronto Department of Computer Science SRS Contents inconsistent inconsistent Can be changed without difficulty E g no TBDs Verifiable every requirement is specified behaviorally E g responses to all classes of input Structural Completeness redundant redundant reduce A process exists to test satisfaction of each requirement Specifies all the things the system must do and all the things it must not do Ranked Must indicate the importance and or stability of each requirement Complete expand condense Uses all terms consistently ambiguous ambiguous expand Doesn t contradict itself Unambiguous Every statement can be read in exactly one way Consistent formalize Department of Computer Science SRS should not include Software Requirements Specification should address Project development plans cost staffing schedules methods tools etc Functionality Lifetime of SRS is until the software is made obsolete What is the software supposed to do External interfaces Lifetime of development plans is much shorter How does the software interact with people the system s hardware other hardware and other software Performance Product assurance plans CM V V test QA etc What is the speed availability response time recovery time of various software functions and so on Different audiences Different lifetimes Attributes What are the portability correctness maintainability security and other considerations Designs Requirements and designs have different audiences Design constraints imposed on an implementation Analysis and design are different areas of expertise Are there any required standards in effect implementation language policies for database integrity resource limits operating environment s and so on I e requirements analysts shouldn t do design Except where application domain constrains the design e g limited communication between different subsystems for security reasons Easterbrook 2004 7 Easterbrook 2004 Source Adapted fromDavis 1990 p183 8 2 University of Toronto University of Toronto Department of Computer Science Typical mistakes Noise text that carries no relevant information to any feature of the problem Silence a feature that is not covered by any text Over specification text that describes a feature of the solution rather than the problem Contradiction text that defines a single feature in a number of incompatible ways Ambiguity text that can be interpreted in at least two different ways Forward reference text that refers to a terms or features yet to be defined Wishful thinking text that defines a feature that cannot possibly be validated Easterbrook 2004 Use
View Full Document
Unlocking...