Supplementary SpecificationsSupplementary Specifications(Chapters 20,22 - Requirements Text)(Chapters 20,22 - Requirements Text)

1

OutlineOutline

Refining the System Definition◦ A More Rigorous Look at Requirements◦ Supplementary Specifications

2

System BehaviorSystem Behavior

Inputs Outputs Functions System Attributes Environmental Attributes

3

What What NotNot to Put in Requirements to Put in Requirements

Project Planning Information◦ May be part of the contract, though

Design Information “what vs. how” Is this a requirement?

“This report will be prepared using visual basic crystal reports software”

4

Requirements versus DesignRequirements versus Design

Requirements comes before design Users make requirement decisions while developers

make design decisions Does this model always work?

5

RequirementsRequirements

Three types◦ Functional

◦ Non-functional (Quality attributes)

◦ Design The two important components that we will use are

◦ Use Case Model

◦ Supplementary Specifications

6

DiscussionDiscussion

Can all functional requirements be captured using use cases?

7

Typical Nonfunctional RequirementsTypical Nonfunctional Requirements

These are the ones Leffingwell & Widrig detail: Usability◦ Ease of use

◦ Bill of rights Reliability◦ System availability

Performance◦ Response time

Supportability

8

We’ll add a couple more of these…

From Bass, et al’s architecture book, which we use in CSSE 374 and 377:

Usability Availability

◦ Similar to Reliability Performance Modifiability

◦ Similar to Supportability Security

◦ New! Testability

◦ New!

Design ConstraintsDesign 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?.

10

““Other” RequirementsOther” Requirements

Deliverables Technical Support Training Requirements

11

Supplementary Specifications DocumentSupplementary Specifications Document

Includes◦ Nonfunctional Requirements,

◦ Design Constraints, and

◦ Other Requirements That are not confined to just one use case Leffingwell & Widrig’s template is available on Page

268/Appendix D We added some specific detail to the Quality

Attributes specs, in your version out on Week 4, Day 1

12

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