Software EngineeringITCS 3155Fall 2008

Dr. Jamie PaytonDepartment of Computer ScienceUniversity of North Carolina at Charlotte

September 16, 2008

Lecture 7Software Product Design

and Project Overview

2

Lecture Overview

Chapter 3Context of Software Product Design

Course Project Overview

3

Software Product Design Process

4

Project Mission Statement

Project mission statementLaunches a development projectDefines the project’s goals and limitsStates the software design problem

Mission statement is main input to product design process

If you don’t have it, you need to create it

5

Project Mission Statement Template

1. Introduction2. Product Vision and Scope3. Target Markets4. Stakeholders5. Assumptions and Constraints6. Business Requirements

6

Introduction, Vision, and Scope

Introduction contains background infoprovides context

Product vision statement is general description of product’s purpose and formProject scope is the work to be done on a project

Often only part of the product visionMay list what will not to be done

1. Introduction2. Product Vision and Scope3. Target Markets4. Stakeholders5. Assumptions and

Constraints6. Business Requirements

7

Stakeholders

A stakeholder is anyone affected by a product or involved in or influencing its development

Product users and purchasersDevelopers and their managersMarketing, sales, distribution, and product support personnelRegulators, inspectors, and lawyers

1. Introduction2. Product Vision and Scope3. Target Markets4. Stakeholders5. Assumptions and

Constraints6. Business Requirements

8

Assumptions and Constraints

An assumption is something that developers take for grantedFeature of the problemExamples: target deployment environments, levels of user support

A constraint is any factor that limits developersRestriction on the solutionExamples: cost and time limits, conformance to regulations

1. Introduction2. Product Vision and Scope3. Target Markets4. Stakeholders5. Assumptions and

Constraints6. Business Requirements

9

Business Requirements

A business requirement is a statement of a client or development organization goal that a product must meet.

Time, cost, quality, or business resultsShould be stated so that it is clear whether it is satisfied (quantitative)Broad goals related to business

• Not detailed product specificationsExample

• AquaLush must be sold by 10% of irrigation companies within 3 years

1. Introduction2. Product Vision and Scope3. Target Markets4. Stakeholders5. Assumptions and

Constraints6. Business Requirements

10

Requirements Engineering

Requirements developmentconcerned with initially establishing requirements • a.k.a. product design

Requirements managementconcerned with controlling and propagating requirements changes

Requirements engineering is creating, modifying, and managing

requirements over a product’s lifetime.

Requirements engineering is creating, modifying, and managing

requirements over a product’s lifetime.

11

Technical Requirements

A technical requirement is a statement of a feature, function, capability, or property that a product must have

Functional requirement• States how a program maps program inputs to outputs

Non-functional requirement• States that software product must have certain properties.

Data requirement• States that certain data must be input to, output from, or

stored by a product

12

Levels of Abstraction

User-level requirementstatement about how a product must support stakeholders in achieving their goals or tasks

Operational-level requirementstatement about inputs, outputs, operations, characteristics, etc. that a product must provide

Physical-level requirementstatement about the physical form of a product, its physical interfaces, or its data formats

13

Functional Requirements

Describe functionality or system servicesFunctional user requirements

High-level statements of what the system should doExample• Irrigation must occur at times set by user

Functional system requirements Describe the system services in detailExample• The system must have a function for setting the irrigation time in

hours and minutes• The system must log all changes to irrigation parameters

14

Non-functional Requirements

Define system properties and constraints Emergent system properties• reliability, response time, storage occupancySystem constraints • I/O device capability, data representationsProcess constraints• Use of particular CASE system, programming language, or

development method

ExamplesThe system must operate after a power failure occurs as if the power failure had not taken place (user)Start-up data must be stored in a medium that will retain data without power (system)

15

Non-functional Classifications

Product requirementsSpecify that delivered product must behave in a particular way• e.g., execution speed, storage overhead, reliability

Organizational requirementsConsequence of organizational policies and procedures • e.g., process standards, implementation requirements, etc.

External requirementsArise from factors external to the system and its development process • e.g., interoperability, legislative, ethical requirements, etc.

16

Requirements Interaction

Conflicts between different non-functional requirements are common Spacecraft system

To minimize weight, the number of separate chips in the system should be minimized.To minimize power consumption, lower power chips should be used.

Conflict!Why?

Which is most critical?

17

Completeness and Consistency

Set of functional requirements should be completeInclude descriptions of all required functions

Set of requirements should be consistentNo conflicts or contradictions in the system descriptions

18

Goals vs. Requirements

Difficult to state non-functional requirements preciselyImprecise requirements are difficult to verify!

May result in expression of a goalA general intention of the user• e.g., ease of use, reasonable performance, maintainability

As developer, prefer verifiable non-functional requirementUsing some measure that can be objectively tested• Quantifiable!

Goals can help convey the intentions of the system users to system developers

Should warn user that difficult to validate

19

Goals vs. Requirements:Examples

A system goalThe system should be easy to use by experienced air traffic controllers and should be organized in such a way that user errors are minimized.

A verifiable non-functional requirementExperienced air traffic controllers shall be able to use all the system functions after a total of two hours training; after this training, the average number of errors made by experienced users shall not exceed two per day.

20

Turning Goals into Requirements: System Property Metrics

Property Measure

Speed Processed transactions/second User/Event response time Screen refresh time

Size

M Bytes Number of ROM chips

Ease of use Training time Number of help frames

Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability

Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure

Portability Percentage of target dependent statements Number of target systems

21

Interaction Design (a.k.a. HCI)

Interaction design Specifying products that people can use effectively and enjoyably• Should be part of requirements development

Dialog design• Dynamics of user interaction

Physical form design• Static characteristics and appearance of interface

(presentation)

22

SRS

The SRS should containA statement of the product design problem • may cite the mission statementA solution to the product design problem

An SRS is the output of the product design process

A software requirements specification (SRS) is a document cataloging all the requirements for a software product.

A software requirements specification (SRS) is a document cataloging all the requirements for a software product.

23

SRS Template

1. Product Description1.1 Product Vision1.2 Business Requirements1.3 Users and Other Stakeholders1.4 Project Scope1.5 Assumptions1.6 Constraints

2. Functional Requirements3. Data Requirements4. Non-Functional Requirements5. Interface Requirements

5.1 User Interfaces5.2 Hardware Interfaces5.3 Software Interfaces

24

Course Project Overview

Course Project30% of total course gradeTeams of 4 people for the project • I assign the teams• One team has 3 people

Project Grading• Four deliverables• Your score = 60% (team_score) + 40% (individual_score)

25

Course Project (cont’d)

ScheduleD1: Software requirements specification• Due: 10/2 D2: Use Case Documentation• Due: 10/16D3: Architecture and Detailed Design Documentation• Due 11/25D4: Prototype and Final Documentation• Due: 12/11

26

Course Project Grading

Course project is 30% of your overall course gradeBreakdown of course project grade

D1: 25%D2: 25%D3: 35%D4: 15%

Grading guidelines will be announced or posted for each deliverableEach deliverable is weighted on team and individual performance

60% team score + 40% individual scoreIndividual score computed using peer assessment, team score

27

Course Project Information

So, what project are you actually going to work on?REU student management tool Online advisorSSDI self-assessment and peer-assessment toolsCollege course evaluation systemTournament management system

Descriptions will be available on course website

28

Deliverable 1: Software Requirements Specification

Due Oct. 2Will need to consult with customer

Elicit needsTranslate into requirementsWe’ll be talking about requirements engineering in class