1

Team Skill 4 - Team Skill 5 -Scope Refining the Systems Definition (Chapters 18-23 of the requirements text)

CSSE 371 Software Requirements and SpecificationDon Bagert, Rose-Hulman Institute of TechnologySeptember 27, 2005

Thanks to Mark Ardis and Steve Chenoweth for some of the slides included.

2

Outline

Scope Establishing Project Scope Managing Your Customer

Refining the System Definition A More Rigorous Look at Requirements Refining Use Cases Supplementary Specifications Ambiguity and Specificity

3

Establishing Project Scope

4

The Shape of Project Scope

Res

ourc

es

Time

Deadline

Deadline

TimeR

esou

rces

5

Brooks' Law

Adding labor to a late project makes it later

Why?

6

Requirements Baseline

Itemized list of features intended for a given release

Must be acceptable to customer Must have reasonable probability of

success

7

Setting Priorities

Customers should decide priorities. Why?

8

Example Priorities

# Feature Priority

1 External RDB support Critical

4 Portability to a new OS Critical

3 Ability to clone new project Important

5 New project wizard Important

2 Implementation of tool tips Useful

9

Assessing Effort

Developers should estimate effort Why?

10

Example Effort

# Feature Priority Effort

1 External RDB support Critical Medium

4 Portability to a new OS Critical High

3 Ability to clone new project Important Low

5 New project wizard Important Low

2 Implementation of tool tips Useful Low

11

Setting the Baseline

Include all "Critical" items Can you deliver those items on time? Add some "Important" items as budget

allows

12

Example Baseline

# Feature Priority Effort

1 External RDB support Critical Medium

4 Portability to a new OS Critical High

3 Ability to clone new project Important Low

Baseline

5 New project wizard Important Low

2 Implementation of tool tips Useful Low

13

Managing Your Customer

14

Suggestions for Dealing with the Client During Development

Include customer in decisions about scope reduction

Negotiate changes to requirements Give yourself some slack Avoid "feature creep"

15

A More Rigorous Look at Requirements

16

Describing System Behavior Through Requirements Include:

Inputs Outputs Functions System Attributes Environmental Attributes

17

Expressing Requirements for System Development

The two important components that we will use are Use Case Model Supplementary Specifications

More on these later

18

What Not to Put in Requirements

Project Planning Information May be part of the contract, though

Design Information (“what vs. how”)

19

Refining Use Cases

20

Use Case Model Components

Use Case Diagram Use Cases

21

Use Case Diagram Example

22

Use Cases

Each feature that will be in the next version of the software (according to the Vision Document) should be involved in at least one use case

The set of use cases cannot be exhaustive, but should include all system uses involving those features as described by stakeholders

Pre-conditions, post-conditions and special requirements are important for development

23

Extending Use Cases

Extend an existing use case instead of redefining it

24

Microwave Extension

User

Cook Food

Cook and Rotate Food

<<extend>>

25

Including Use Cases

Frequent sequences of events may be defined as use cases

Including a use case is like calling a subroutine

26

Microwave Inclusion

User

Cook Food

Set Timer

<<include>>

27

Cook Food Inclusion

D. Basic flow:1. User opens door and places food in unit

2. User performs Set Timer use case

3. User pushes start button

4. Unit cooks food

5. Unit beeps

28

Supplementary Specifications

29

Types of Requirements

Functional Requirements Nonfunctional Requirements Design Constraints “Other” Requirements

30

Typical Nonfunctional Requirements

Usability Reliability Performance Supportability

That is, nonfunctional requirements generally focus on quality attributes

31

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? Because it is part of what the customer wants or needs in the system to be developed.

32

“Other” Requirements

Deliverables (e.g. user documentation, other artifacts to be supplied by the developer – may in part depend on who’s doing the maintenance

Technical Support Training Requirements

Some organizations will include these in the “nonfunctional requirements”

33

Supplementary Specifications Document

Includes Nonfunctional Requirements, Design Constraints, and Other Requirements

That are not confined to just one use case

34

Ambiguity and Specificity

35

Basic Problem

The requirements must be both understandable and unambiguous

Balancing the two is sometimes difficult! Client – needs it to be understandable Software Team – needs it to be unambiguous