1 team skill 4 - team skill 5 - scope refining the systems definition (chapters 18-23 of the...
Post on 20-Dec-2015
216 views
TRANSCRIPT
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