Software Requirements and Spec
Software Requirements and Spec CSSE 371
Popular in Course
Popular in Computer Science and Engineering
This 8 page Class Notes was uploaded by Miss Terry Reichel on Monday October 19, 2015. The Class Notes belongs to CSSE 371 at Rose-Hulman Institute of Technology taught by Staff in Fall. Since its upload, it has received 10 views. For similar materials see /class/225099/csse-371-rose-hulman-institute-of-technology in Computer Science and Engineering at Rose-Hulman Institute of Technology.
Reviews for Software Requirements and Spec
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 10/19/15
Supplementary Speci cations Template This document has two parts 0 The Supplementary Speci cation Template from Lef ngwell amp Widrig adjusted to show the nonfunctional requirements as identi ed by Bass et al 0 Two Notes 7 The rst of these is about links from here two other documents The second is a lengthy help sheet for writing scenarios about the nonfunctional requirements The Template Supplementary Speci cations for ltrequirements system or project namegt1 Title authors etc go rst 1 Introduction 11 Purpose State the purpose of the document to collect all functional requirements not expressed in the usecase model as well as nonfunctional requirements and design constraints 12 Scope 13 De nitions Acronyms and Abbreviations 14 References 15 Overview an additional section included by some users of this format 2 Functionality or Functional Requirements Describe the functional requirements of the system for those requirements that are expressed in the natural language style or are otherwise not included in the use case model See p 258 21 ltFunctional Requirement One etc if a listing of these is done gt 3 Usability Describe the principal scenarios that affect usability See pp 259260 and use the Scenario format shown in Note 2 below with related details for Usability See also the Yale Style Guide httpwwwwebstyleguidecom or User and Task Analysis for Interface Design by JoAnn T Hackos and Janice C Redish Wiley Computer Publishing 1998 ISBN 0471178314 31 ltUsability Requirement One gt 1 From Leffingwell amp Widrig Second Edition except for the list of nonfunctional requirements and their scenarios which are from Bass et al 41 61 71 81 91 Availability Describe the principal scenarios for dependability such as reliability andor availability These are different See pp 2612 web links such as httpwwwweibullcomSystemRelWebavailabilityhtm or the book Software Reliability Engineering by John D Musa cited in your syllabus Use the Scenario format shown in Note 2 below with related details for Availability ltAvailability Requirement One gt Performance ltPerformance Requirement One gt Describe the principal required performance and capacity scenarios of the system expressed quantitatively where possible and related to use cases where applicable Eg It s unlikely they all have to run equally fast Related terms and requirements are capacity throughput and response time See p 262 in your book or Performance Solutions A Practical Guide to Creating Responsive Scalable Software by Connie U Smith Lloyd Williams cited in your syllabus Use the Scenario format shown in Note 2 below with related details for Performance Modi ability This is close to Leffingwell amp Widrig s Supportability requirement State the requirements that enhance system modifiability supportability or maintainability See pp 2623 in your book Use the Scenario format shown in Note 2 below with related details for Modifiability ltModifiability Requirement One gt Security Describe the principal security scenarios for the system using the Scenario format shown in Note 2 below with related details for Security System security is a big area 7 look for suggested topics also from other resources One example Security Architecture Design Deployment amp Operations by Christopher M King et al OsbomeMcGrawHill 2001 ISBN 0072133856 ltSecurity Requirement One gt Testability Describe the principal testability scenarios for the system using the Scenario format shown in Note 2 below with related details for Testability ltTestability Requirement One gt Design Constraints State the design or development constraints imposed on the system or development process See pp 263266 in your book ltDesign Constraint One gt Documentation Online Documentation and Help System Requirements State the requirements for user andor administrator documentation 11 Purchased Components List the purchased components used with the system including the planned version numbers and availability support termination dates licensing or usage restrictions some have a runtime license fee some don t and J quot39 quotquot 39 r 39 quotquoty 1 39 to run this users must have etc 12 Interfaces De ne the interfaces that must be supported by the application 121 User Interfaces 122 Hardware Interfaces 123 Software Interfaces 124 Communications Interfaces 13 Licensing Requirements Describe the licensing and usage enforcement requirements or other restrictions for usage security and accessibility for the system you will be building 14 Legal Copyright and Other Notices State any required legal disclaimers warranties copyright notices patent notices trademarks or logo compliance issues 15 Applicable Standards Reference any applicable standards and the speci c sections of any such standards that apply 16 Internationalization and Localization State any requirements for support and application of different user languages and dialects 15 Physical Deliverables Define any specific deliverable artifacts required by the user or customer 16 Installation and Deployment Describe any specific con guration or target system preparation required to support installation and deployment of the system The Note Note 1 You re not done yet As the book says pp 2667 a welldefined set of requirements should include links or crossreferences from the use cases to non functional requirements and other pieces of this Supplementary Specification And these ties should be welldefined so they don t grow tired as changes are made to either document or new versions of the documents are issued Note 2 Scenario format for the nonfunctional requirements in general Source of stimulus This is some entity a human a computer system or any other actuator that generated the stimulus Stimulus The stimulus is a condition that needs to be considered when it arrives at a system Environment The stimulus occurs within certain conditions The system may be in an overload condition or may be running when the stimulus occurs or some other condition may be true Artifact Some artifact is stimulated This may be the whole system or some pieces of it Response The response is the activity undertaken after the arrival of the stimulus Response measure When the response occurs it should be measurable in some fashion so that the requirement can be tested And Possible values of these portions of the scenario for different Quality Attributes from Bass et all 3 Usabilit Source End user Stimulus Wants to learn system features use system efficiently minimize impact of errors adapt system feel comfortable Artifact System Environment At runtime or con gure time Response System provides one or more of the following responses To support learn system features Help system is sensitive to context interface is familiar to user interface is usable in an unfamiliar context To support use system efficiently Aggregation of data and or commands support for efficient navigation within a screen distinct Views with consistent operations comprehensive searching multiple simultaneous activities To minimize impact of errors Undo cancel recover from system failure recognize and correct user error retrieve forgotten password verify system resources To adapt system 2 Software Architecture in Practice Second Edition by Len Bass Paul Clements and Rick Kazman AddisonWesley 2003 ISBN 0321154959 pp 71 Customizability internationalization To feel comfortable Display system state work at the user s pace Response Measure Task time number of errors number of problems solved user satisfaction gain of user knowledge ratio of successful operations to total operations amount of time data lost 9 Here s a sample usability scenario from Bass et al Source Users Stimulus Minimize impact of errors Artifact System Environment At runtime Response Wishes to cancel current operations Response Measure Cancellation takes less than one second 4 Availability Source Internal to the system external to the system Stimulus Fault omission crash timing response Artifact System s processors communication channels persistent storage processes Environment Normal operation degraded mode ie fewer features a fall back solution Response System should detect event and do one or more of the following Record it Notify appropriate parties including the user and other systems Disable sources of events that cause fault or failure according to defined rules Be unavailable for a prespecified interval where interval depends on criticality of system Response Measure Time interval when the system must be available Availability time Time interval in which system can be in degraded mode Repair time 9 Here s a sample availability scenario from Bass et al Source EXtemal to the system Stimulus Unanticipated message Artifact Process Environment Normal operation Response Inform operator continue to operate Response Measure No downtime 5 Performance Source One of a number of independent sources possibly from within system Stimulus Periodic events arrive sporadic events arrive stochastic events arrive Artifact System Environment Normal mode overload mode Response Processes stimuli changes level of service Response Measure Latency deadline throughput jitter miss rate data loss 9 Here s a sample performance scenario from Bass et al Source Users Stimulus Initiate transactions Artifact System Environment Under normal operations Response Transactions are processed Response Measure With average latency of two seconds 6 Modifiability Source End user developer system administrator Stimulus Wishes to adddeletemodifyvary functionality quality attribute capacity Artifact System user interface platform environment system that interoperates with target system Environment At runtime compile time build time design time Response Locates places in architecture to be modified makes modification without affecting other functionality tests modification deploys modification Response Measure Cost in terms of number of elements affected effort money extent to which this affects other functions or quality attributes 9 Here s a sample modifiability scenario from Bass et al Source Developer Stimulus Wishes to change the UI Artifact Code Environment At design time Response Modification is made with no side effects Response Measure In 3 hours 6 Security Source Individual or system that is Correctly identified identified incorrectly of unknown identity Who is Intemalexternal authorizednot authorized With access to Limited resources vast resource Stimulus Tries to Display data changedelete data access system services reduce availability to system services Artifact System services data within system Environment Either online or of ine connected or disconnected firewalled or open Response Authenticates user hides identity of the user blocks access to data andor services allows access to data andor services records accessmodifications or attempts to accessmodify dataservices by identity stores data in an unreadable format recognizes an unexplainable high demand for services and informs a user or another system and restricts availability of services Response Measure Timeeffortresources required to circumvent security measures with probability of success probability of detecting attack probability of identifying individual responsible for attack or accessmodification of data andor services percentage of services still available under denialofservice attack restore dataservices extent to which data services damaged and0r legitimate access denied 9 Here s a sample security scenario from Bass et al Source Correctly identified individual Stimulus Tries to modify information Artifact Data within the system Environment Under normal operations Response System maintains audit trail Response Measure Correct data is restored within a day 6 Testabilit Source Unit developer Increment integrator System veri er Client acceptance tester System user Stimulus Analysis architecture design class subsystem integration completed system delivered Artifact Piece of design piece of code complete application Environment At design time at development time at compile time at deployment time Response Provides access to state values provides computed values prepares test environment Response Measure Percent executable statements executed Probability of failure if fault exists Time to perform tests Length of longest dependency chain in a test Length of time to prepare test environment 9 Here s a sample testability scenario from Bass et al Source Unit tester Stimulus Performs unit test Artifact Component of the system Environment At the completion of the component Response Component has interface for controlling behavior and output of the component is observable Response Measure Path coverage of 85 is achieved within 3 hours