Lecture 7 Software Product Design and Project Overview

Transcription

1 Lecture 7 Software Product Design and Project Overview Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 16, 2008

2 Lecture Overview Chapter 3 Context of Software Product Design Course Project Overview 2

3 Software Product Design Process 3

4 Project Mission Statement Project mission statement Launches a development project Defines the project s goals and limits States the software design problem Mission statement is main input to product design process If you don t have it, you need to create it 4

5 Project Mission Statement Template 1. Introduction 2. Product Vision and Scope 3. Target Markets 4. Stakeholders 5. Assumptions and Constraints 6. Business Requirements 5

6 Introduction, Vision, and Scope Introduction contains background info provides context Product vision statement is general description of product s purpose and form Project scope is the work to be done on a project Often only part of the product vision May list what will not to be done 1. Introduction 2. Product Vision and Scope 3. Target Markets 4. Stakeholders 5. Assumptions and Constraints 6. Business Requirements 6

7 Stakeholders A stakeholder is anyone affected by a product or involved in or influencing its development Product users and purchasers Developers and their managers Marketing, sales, distribution, and product support personnel Regulators, inspectors, and lawyers 1. Introduction 2. Product Vision and Scope 3. Target Markets 4. Stakeholders 5. Assumptions and Constraints 6. Business Requirements 7

8 Assumptions and Constraints An assumption is something that developers take for granted Feature of the problem Examples: target deployment environments, levels of user support A constraint is any factor that limits developers Restriction on the solution Examples: cost and time limits, conformance to regulations 1. Introduction 2. Product Vision and Scope 3. Target Markets 4. Stakeholders 5. Assumptions and Constraints 6. Business Requirements 8

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 results Should be stated so that it is clear whether it is satisfied (quantitative) Broad goals related to business Not detailed product specifications Example AquaLush must be sold by 10% of irrigation companies within 3 years 1. Introduction 2. Product Vision and Scope 3. Target Markets 4. Stakeholders 5. Assumptions and Constraints 6. Business Requirements 9

10 Requirements Engineering Requirements development concerned with initially establishing requirements a.k.a. product design Requirements management Requirements engineering is is creating, modifying, and managing requirements over a product s lifetime. concerned with controlling and propagating requirements changes 10

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 11

12 Levels of Abstraction User-level requirement statement about how a product must support stakeholders in achieving their goals or tasks Operational-level requirement statement about inputs, outputs, operations, characteristics, etc. that a product must provide Physical-level requirement statement about the physical form of a product, its physical interfaces, or its data formats 12

13 Functional Requirements Describe functionality or system services Functional user requirements High-level statements of what the system should do Example Irrigation must occur at times set by user Functional system requirements Describe the system services in detail Example The system must have a function for setting the irrigation time in hours and minutes The system must log all changes to irrigation parameters 13

14 Non-functional Requirements Define system properties and constraints Emergent system properties reliability, response time, storage occupancy System constraints I/O device capability, data representations Process constraints Use of particular CASE system, programming language, or development method Examples The 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) 14

15 Non-functional Classifications Product requirements Specify that delivered product must behave in a particular way e.g., execution speed, storage overhead, reliability Organizational requirements Consequence of organizational policies and procedures e.g., process standards, implementation requirements, etc. External requirements Arise from factors external to the system and its development process e.g., interoperability, legislative, ethical requirements, etc. 15

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? 16

17 Completeness and Consistency Set of functional requirements should be complete Include descriptions of all required functions Set of requirements should be consistent No conflicts or contradictions in the system descriptions 17

18 Goals vs. Requirements Difficult to state non-functional requirements precisely Imprecise requirements are difficult to verify! May result in expression of a goal A general intention of the user e.g., ease of use, reasonable performance, maintainability As developer, prefer verifiable non-functional requirement Using 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 18

19 Goals vs. Requirements: Examples A system goal The 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 requirement Experienced 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. 19

20 Turning Goals into Requirements: System Property Metrics Property Speed Size Ease of use Reliability Robustness Portability Measure Processed transactions/second User/Event response time Screen refresh time M Bytes Number of ROM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems 20

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) 21

22 SRS A software requirements specification (SRS) is is a document cataloging all all the requirements for for a software product. The SRS should contain A statement of the product design problem may cite the mission statement A solution to the product design problem An SRS is the output of the product design process 22

23 SRS Template 1. Product Description 1.1 Product Vision 1.2 Business Requirements 1.3 Users and Other Stakeholders 1.4 Project Scope 1.5 Assumptions 1.6 Constraints 2. Functional Requirements 3. Data Requirements 4. Non-Functional Requirements 5. Interface Requirements 5.1 User Interfaces 5.2 Hardware Interfaces 5.3 Software Interfaces 23

24 Course Project Overview Course Project 30% of total course grade Teams 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) 24

25 Course Project (cont d) Schedule D1: Software requirements specification Due: 10/2 D2: Use Case Documentation Due: 10/16 D3: Architecture and Detailed Design Documentation Due 11/25 D4: Prototype and Final Documentation Due: 12/11 25

26 Course Project Grading Course project is 30% of your overall course grade Breakdown of course project grade D1: 25% D2: 25% D3: 35% D4: 15% Grading guidelines will be announced or posted for each deliverable Each deliverable is weighted on team and individual performance 60% team score + 40% individual score Individual score computed using peer assessment, team score 26

27 Course Project Information So, what project are you actually going to work on? REU student management tool Online advisor SSDI self-assessment and peer-assessment tools College course evaluation system Tournament management system Descriptions will be available on course website 27

28 Deliverable 1: Software Requirements Specification Due Oct. 2 Will need to consult with customer Elicit needs Translate into requirements We ll be talking about requirements engineering in class 28