lecture 7 software product design andproject overview · lecture 7 software product design ......
TRANSCRIPT
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