Supplementary Specifications (Chapters 20,22 - Requirements Text)

Supplementary Specifications(Chapters 20,22 - Requirements Text) by Steve & Chandan (Along with others in the past! - See notes, below) Question 1

System Behavior • Inputs • Outputs • Functions • System Attributes • Environmental Attributes

What Not to Put in Requirements • Project Planning Information • May be part of the contract, though • Design Information “what vs. how” • Is this a requirement? “The system will track web-traffic using Google Analytics and the results will be presented via a scatter-chart” Questions 2,3

Requirements versus Design • Requirements comes before design • Users make requirement decisions while developers make design decisions • Does this model always work?

Requirements • Three types • Functional • Non-functional (Quality attributes) • Design constraints • The two important components that we will use are • Use Case Model • Supplementary Specifications

Functional Requirements – beyond use cases • Most strategic thing on these functional ones – Describe the key features, from the standpoint of what’s required! Like, for the Graduation Planning System, 3.1.2 The system will capture ‘what if’ plans done by the student, in whatever state they choose to leave them, for future reference. 3.1.2.1 These will be saved to the server, and backed up automatically. 3.1.3 The student can, at any point, swap their ‘current’ plan for a ‘what if’ plan, to change their real plan. “Radix” numbering is usually used in documents like this spec.

Functional Requirements – beyond use cases • See the list on p 258 of Leffingwell, of other kinds of Functional Requirements. • Can be a huge number of these functional requirements in some systems • What’s important in these? • Depends on the type of product • Depends on the knowledge of the developers, for that type of product • Goal is for the right product to be developed

Then there are the Nonfunctional Requirements These are the ones Leffingwell & Widrig detail: • Usability • Ease of use • Bill of rights • Reliability • System availability • Performance • Response time • Supportability Questions 4,5

We’ll add a couple more of these… From Bass, et al’s architecture book, which we use in CSSE 377: • Usability • Availability • Similar to Reliability • Performance • Modifiability • Similar to Supportability • Security • New! • Testability • New!

Design Constraints • Restriction of design options (e.g. what database to use) • Process (e.g. must use ISO or IEEE software engineering standards) • Regulations (e.g. FDA) • Why are these in the requirements, if they involve design?. Question 6

“Other” Requirements • Deliverables • Technical Support • Training Requirements • Internatonalization

Supplementary Specifications Document • Includes • Functional requirements that are not specified using use cases • Nonfunctional Requirements, • Design Constraints, and • Other Requirements • That are not confined to just one use case • Leffingwell & Widrig’s template for the Supplementary Spec is available on Page 268/Appendix D. • Quality Attributes specs – available under Week 4, Day 1 in your schedule. Question 7

How do you ”detail” a quality attribute? • Do “Scenarios” in which they typically would apply • Similar to, but not the same as Use Cases for functionality • These Scenarios make it easier to see what to shoot for in meeting these requirements, like: • How to design and implement for them • How to test them in acceptance tests

What do the Quality Attribute Scenarios look like? • Source of stimulus: • Stimulus: • Environment: • Artifact: • Response: • Response measure:

Quality Attribute Example – Usability: • 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

Supplementary Specifications (Chapters 20,22 - Requirements Text)