1University of TorontoDepartment of Computer Science© Easterbrook 20041Lecture 5:Requirements Specifications Why we need to write specifications Purpose and audience Choosing an appropriate size and formality Desiderata for Specifications Properties of good specifications Typical problems What not to include Structure of a requirements document IEEE standardUniversity of TorontoDepartment of Computer Science© Easterbrook 20042Software Requirements Specification Purpose Communicates an understanding ofthe requirementsexplains both the application domainand the system to be developed ContractualMay be legally binding!Expresses agreement and a commitment Baseline for evaluating subsequentproductssupports system testing, verificationand validationenough information to verify whetherdelivered system meets requirements Baseline for change controlrequirements change, software evolves Audience Users, PurchasersMost interested in system requirementsNot generally interested in detailedsoftware requirements Systems Analysts, RequirementsAnalystsWrite various specifications that inter-relate Developers, ProgrammersHave to implement the requirements TestersDetermine that the requirements havebeen met Project ManagersMeasure and control the analysis anddevelopment processes How do we communicate the Requirements to others? It is common practice to capture them in an SRS But an SRS doesn’t need to be a single paper document...University of TorontoDepartment of Computer Science© Easterbrook 20043Appropriate Specification Consider two different projects:A) Tiny project, 1 programmer, 2 months workprogrammer talks to customer, then writes up a 5-page memoB) Large project, 50 programmers, 2 years workteam of analysts model the requirements, then document them in a 500-page SRSProject AProject BPurpose of spec?Crystalizes programmer’sunderstanding; feedbackto customerBuild-to document; mustcontain enough detail forall the programmersManagementview?Spec is irrelevant; havealready allocatedresourcesWill use the spec toestimate resource needsand plan the developmentReaders?Primary: Spec author;Secondary: CustomerPrimary: programmers,testers, managers;Secondary: customersUniversity of TorontoDepartment of Computer Science© Easterbrook 20044A complication: Procurement An ‘SRS’ may be written by… …the procurer: 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 …the bidders: 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 …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 & developer2University of TorontoDepartment of Computer Science© Easterbrook 20045Desiderata for Specifications Valid (or “correct”) Expresses only the real needs of thestakeholders (customers, users,…) Doesn’t contain anything that isn’t“required” Unambiguous Every statement can be read inexactly one way Complete Specifies all the things the systemmust do… ...and all the things it must not do! Conceptual Completeness E.g. responses to all classes of input Structural Completeness E.g. no TBDs!!! Understandable (Clear) E.g. by non-computer specialists Consistent Doesn’t contradict itself I.e. is satisfiable Uses all terms consistently Ranked Must indicate the importance and/orstability of each requirement Verifiable A process exists to test satisfactionof each requirement“every requirement is specifiedbehaviorally” Modifiable Can be changed without difficulty Good structure and cross-referencing Traceable Origin of each requirement is clear Facilitates referencing ofrequirements in future documentationSource: Adapted from IEEE-STD-830-1998University of TorontoDepartment of Computer Science© Easterbrook 20046There is no Perfect SRS!incompleteincompleteincompletenot understandablenot understandablenot understandableambiguousambiguousambiguousredundantredundantredundantinconsistentinconsistentinconsistentaddexplanationsresolvereduceexpandexpandcondenseformalize…etc!University of TorontoDepartment of Computer Science© Easterbrook 20047SRS Contents Software Requirements Specification should address: Functionality. What is the software supposed to do? External interfaces. How does the software interact with people, the system's hardware, otherhardware, and other software? Performance. What is the speed, availability, response time, recovery time of various softwarefunctions, and so on? Attributes. What are the portability, correctness, maintainability, security, and otherconsiderations? Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies fordatabase integrity, resource limits, operating environment(s) and so on?University of TorontoDepartment of Computer Science© Easterbrook 20048SRS should not include… Project development plans cost, staffing, schedules, methods, tools, etc Lifetime of SRS is until the software is made obsolete Lifetime of development plans is much shorter Product assurance plans CM, V&V, test, QA, etc Different audiences Different lifetimes Designs Requirements and designs have different audiences Analysis and design are different areas of expertise 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.Source: Adapted fromDavis, 1990, p1833University of TorontoDepartment of Computer Science© Easterbrook 20049Typical mistakes Noise text that carries no relevant informationto any feature of the
View Full Document
Unlocking...