4 Software Product Design Analysis Ch4

8/2/2019 4 Software Product Design Analysis Ch4

1/27

Page 1

ENGR2720U

ENGR2720

Software Design II

Slides modified from: Introduction to Software Engineering Design(C. Fox)

Software Product Design

Context and Analysis


2/27

Page 2

ENGR2720U

Product Design Analysis


3/27

Page 3

ENGR2720U

Objectives

To explain the product design process as top-down and user centered

To list and explain several needs elicitation

heuristics and techniquesTo describe how to analyze and documentneeds elicitation results

To explain how to check analysis results


4/27

Page 4

ENGR2720U

Software Product Design Process

Generic Software Product DesignProject Mission Statement : Problem

SRS : Solution

Project Mission

Statement

SRS

[adequate]

[else]

[complete]

[else]

Analyze Product

Design Problem

Elicit/Analyze

Detailed Needs

Generate/Improve

Candidate Requirements

Evaluate Candidate

Requirements

Select Requirements

Finalize Requi rements


5/27

Page 5

ENGR2720U

Top-Down Process

Design resolution begins with abstractrequirements and refines them

Designers move from user-level tooperational-level to physical levelrequirements

Main activity in the resolution loop


6/27

Page 6

ENGR2720U

User-Centered Process

Stakeholder focusDetermine needs of allstakeholders and include them in evaluation

Empirical evaluation

Collect data aboutneeds, desires, and design quality

IterationImprove design repeatedly untiladequate


7/27Page 7

ENGR2720U

Stakeholder Roles

Activity Stakeholders RoleAnalyze ProductDesign Problem Clarify project mission statementAnswer questionsElicit Needs Answer questions

Be subjects of empirical studiesAnalyze Needs Answer questionsReview and validate models and documents

Participate in analysis with designersGenerate/ImproveAlternatives Participate in generation and improvement

Evaluate Alternatives Answer questionsBe subject of empirical studiesParticipate in evaluation with designers

Select Alternatives Participate in selection with designersFinalize Design Review and validate requirements


8/27Page 8

ENGR2720U

Aqualush Exercise

Read through the Aqualush process that wasfollowed to finalize the requirements in order tocreate an SRS on page 102 in the textbook.

Summarize the steps taken in bullet form.


9/27Page 9

ENGR2720U

Needs versus Requirements

Stakeholder needs and desires define theproduct design problem.

Requirements specify the product design

solution.Needs and requirements statements aresimilar, but the heart of product design ismoving from needs to requirements.

Conflicting needs and desires

Tradeoffs (needs and constraints)

Ways of satisfying needs and desires


10/27Page 10

ENGR2720U

Needs Elicitation Challenges 1

Needs and desires must be understood inthe context of the problem domain.

Stakeholders may not be available.Stakeholder responses are often hard tounderstand and sort out.


11/27Page 11

ENGR2720U

Needs Elicitation Challenges 2

Stakeholders often cannot explain their work,or articulate their needs and desires.

Stakeholders make mistakes, leave thingsout, and are misleading.

Stakeholders often dont understand the

capabilities and limitations of technology.


12/27Page 12

ENGR2720U

Elicitation Heuristics

Learn about the problem domain first.

Determine stakeholder goals as the

context of stakeholder needs and desires.Study user tasks.


13/27Page 13

ENGR2720U

Elicitation Techniques 1

InterviewsDesigners questionstakeholders

Most important technique

Many ways to do interviews

Recording responses

ObservationDesigners watch users work

Better than having people explain their work

Several of the right people, several times

Talking out loud

Recording observations


14/27Page 14

ENGR2720U


Focus groupsInformal discussion led by afacilitator Six to nine people

Facilitator keeps people on task

User-level requirements

Elicitation workshopsDirected discussion ledby a facilitator

More directed and detailed than a focus group Specific goals

Needs or desires or product features and details

Requires committed stakeholders


15/27Page 15

ENGR2720U


Document studies

Books (problem domain)

Policies and procedures

Process improvement studies Development documentation

Problem and bug reports

Suggestions

Competitive product studies

Products themselves

Reviews and market studies


16/27


17/27Page 17

ENGR2720U

Documenting the Problem Domain

Organize notes

Make a problem domain glossary

Make an organization chart

Make UML activity diagrams


18/27Page 18

ENGR2720U

Categories are based on roles, not individuals, jobs,or titles.

Documenting Goals

Astakeholders-goals list is acatalog of important stakeholder

categories and their goals.

Look at Table 4-3-1 as an example of the Aqualush stakeholders-goalslist. What is the pupose of this goals list?


19/27

Page 19

ENGR2720U

Documenting Needs and Desires

A need statement should

Name the stakeholder category or categories

State one specific need

Be a positive declarative sentence

Often requires interpretation of raw data

Aneed statement documents a singleproduct feature, function, or property needed

or desired by one or more stakeholders.


20/27

Page 20

ENGR2720U

Need statement Example

See table 4-3-2 in the text book.


21/27

Page 21

ENGR2720U

Organizing Need Statements

Needs lists should be arranged hierarchicallyTry arrangements with note cards

Prioritize needs Numbers

Hi/Med/Lo

Consult stakeholders

Aneeds list catalogs need statements.


22/27


23/27

Page 23

ENGR2720U

Modeling

Many kinds of models can represent theproblem and help designers understand it.

Many modeling notations and techniques

useful for analysis will be discussed later. Various UML diagrams

Use case descriptions, user interface diagrams,dialog maps

Conceptual modeling, use case modeling


24/27

Page 24

ENGR2720U

Checking Needs Documentation 1

CorrectnessA statement is correct if it iscontingent and accords with the facts.

ScopeA goal or need is within the project

scope if it can be satisfied using the plannedfeatures of the product created by the project.

TerminologicalconsistencyTerminologicalconsistency is using words with the same

meaning and not using synonyms.


25/27

Page 25

ENGR2720U

UniformityA description has uniformity when ittreats similar items in similar ways.

CompletenessDocumentation is complete

when it contains all relevant material.Review activities Developers should use checklists

Stakeholders should review documents

Table 4-3-4 shows a good samples needschecklist to assure that the above needs areconsistent.

Checking Needs Documentation 2

ENGR U


26/27

Page 26

ENGR2720U

Summary 1

The product design process is essentially top-down and user centered.

Product design begins with design problem

analysis.Stakeholders can play many roles in productdesign.

Needs define the product design problem;requirements state the solution.

ENGR2720U


27/27

ENGR2720U

Summary 2

Designers should understand the problemdomain and stakeholder goals before elicitingneeds.

Needs can be elicited in many ways andpreferably by direct contact with stakeholders.

Many kinds of models can help understand theproblem.

Needs must be documented, organized, andchecked.

4 Software Product Design Analysis Ch4

Documents

Transcript of 4 Software Product Design Analysis Ch4