29
1 Team Skill 3 - Defining the System (Chapters 14-17 of the requirements text) CSSE 371 Software Requirements and Specification Don Bagert, Rose-Hulman Institute of Technology September 20, 2005 Thanks to Mark Ardis and Steve Chenoweth for some of the slides included.

1 Team Skill 3 - Defining the System (Chapters 14-17 of the requirements text) CSSE 371 Software Requirements and Specification Don Bagert, Rose-Hulman

  • View
    213

  • Download
    0

Embed Size (px)

Citation preview

1

Team Skill 3 -Defining the System(Chapters 14-17 of the requirements text)

CSSE 371 Software Requirements and Specification Don Bagert, Rose-Hulman Institute of TechnologySeptember 20, 2005

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

2

Outline Use Cases Organizing Requirements Vision Document Product Management

3

Use Cases

4

What is a Use Case? Sequences of actions Performed by system of interest Observable result of value to a particular

actor

5

Use Case Model - Development Steps

1. Identify the actors

2. Identify the use cases

3. Identify actor/use case relationships

4. Outline use cases

5. Refine use cases

6

1. Identify the Actors Who uses the system? Who gets/provides information from/to

system? Who supports the system? What other systems interact with this system?

7

2. Identify the Use Cases What are the intentions of each actor with

respect to the system? Give a descriptive name:

Start with an action verb Describes goal or intent

Give a one-sentence description

8

3. Identify Actor/Use Case Relationships

Draw a diagram showing relationships between actors and use cases

Eat food

Buy foodParent Child

9

4. Outline Use Cases Describe sequence of events in basic flow

(sunny day scenario) Describe sequences of events in alternate

flows (rainy day scenarios)

10

5. Refine Use Cases Describe sequences of events for flows Describe pre-conditions Describe post-conditions Fill in special requirements

11

Use Case TemplateA. Name

B. Brief description

C. Actors

D. Basic flow

E. Alternate flows

F. Pre-conditions

G. Post-conditions

H. Special requirements

12

Microwave Example

User

Cook Food

13

Cook Food Use Case – Slide 1 of 4A. Name: Cook Food

B. Brief description: User places food in microwave and cooks it for desired period of time at desired power level.

C. Actors: User

14

Cook Food Use Case – Slide 2 of 4D. Basic flow:

1. User opens door and places food in unit

2. User enters time for cooking

3. User pushes start button

4. Unit cooks food

5. Unit beeps

15

Cook Food Use Case – Slide 3 of 4E. Alternate flows

1. User cancels time before starting

2. User cancels cooking before finished

3. User selects reduced power level before pushing start button

16

Cook Food Use Case – Slide 4 of 4F. Pre-conditions

Unit is plugged in Unit is in ready state

G. Post-conditions Food is cooked or user cancelled operation

H. Special requirements Timer should display remaining time to finish while

cooking Default power setting should be "high"

17

Organizing Requirements

18

Organization Techniques Dividing requirements for complex systems into

subsystems

Product Families A series of products with closely related requirements Product lines – a new way of viewing software products

Investing in infrastructure to build product families Develop systematic approach to building flexible application

generators Commonality analysis – used to determine if use of a product

line will be beneficial

19

Economics of Families

CurrentPractice

Number of Family Members

Cumulative Cost Product Line

Approach

20

Example Families Toyota automobiles and trucks IBM 360 computers Software?

21

The Vision Document

22

Purpose Every software project will benefit from having a

Vision document. The Vision document describes the application in

general terms, including descriptions of the target market, the system users, and the application features.

The Vision document defines, at a high level of abstraction, both the problem and the solution.

It gives the development team “common goals and a common playbook.”

23

Vision Document Template1. Introduction

2. User Description

3. Product Overview

4. Feature Attributes

5. Product Features

6. Exemplary Use Cases

7. Other Product Requirements

8. Documentation Requirements

9. Glossary

24

Product Management

25

Rationale Every project needs an individual champion or a small champion

team to advocate for the product. In a software products company, the product manager plays the role

of the champion. The product manager drives the whole product solution: the

application itself, support, user conveniences, documentation, and the relevant commercial factors.

The Product Manager does high-level tasks – Listens to all the stakeholders Negotiates amongst them Manages and funds project people Communicates features and releases to the outside world Advocates the product to everyone “Owns” the vision statement!

26

Product Manager in the Hierarchy Chart

27

Driving the Product Vision

28

A Product Manager’s Day Plan scenarios in which products provide answers

These pieces make the product manager’s vision!

29

Product Types from a Marketing POV

There are two major variations: A “custom” product for a particular customer

or small group of customers – They often act directly as “external clients”

A “general” product for a target market – An executive or the product manager is the “internal client” for these future customers