What is

Published on February 2017 | Categories: Documents | Downloads: 101 | Comments: 0 | Views: 1239
of 35
Download PDF   Embed   Report

Comments

Content

Lecture 4: Product Vision and Project Scope
Requirements Management and Systems Engineering (ITKS451), Autumn 2008

Artem Katasonov University of Jyväskylä

University of Jyväskylä

In the previous episode:
g

Quality of requirements starts with providing basic training in RE for both analysts and customers, and other strategic quality management activities (“cleaning the kitchen”). Quality assurance (“keeping the lid closed”) and quality control (“inspecting soup and removing bugs”) are important also, but without knowledge will hardly be effective.

g

The quality of requirements is usually defined with a set of factors, including completeness, correctness, consistency, etc.

2

University of Jyväskylä

In the previous episode (2):
g

g

The most risky factor of all is completeness. Missing requirements are difficult to detect, and software defects due to missing requirements are usually very difficult to fix. In assuring or verifying the completeness of requirements, identifying all the stakeholders of the software system is an important task. For this, orthogonal 3-dimensional framework (domain, system level, goal/means) is a useful tool.
Development domain supra-system: Development company Goals Operation domain

system: Project

system: Software

supra-system1: supra-system2: Organization Society

Goals

Sponsor

Company owners

Users

Owners

Subjects

Means

Means

Developers

Company management

Maintenance staff

Management

Government, Police

3

University of Jyväskylä

The first step
Business Requirements

Features
Business Rules

Vision and Scope Document
User Requirements Quality Attributes

Use-Case Document

Constraints

System Requirements

Functional Requirements

External Interfaces

Software Requirements Specification (SRS)

4

University of Jyväskylä

Business requirements and vision (features)
g

Business requirements – represent high-level objectives of the organization or the customer requesting the system. – Correspond to Jackson’s outer requirements. Features – Provide the original abstract solution to the business requirements to be later elaborated into specific requirements. – Later used as bulleted items in the product description. – Wiegers (2003): A feature is a set of logically related functional requirements that provides a capability to the user and enables the satisfaction of a business objective.. Why necessarily functional?? – A feature may look as a requirement of any type (user, functional, external interface, etc.).

g

5

University of Jyväskylä

Features
g

Examples of features – Location-based restaurants information system for mobile phones:
– Allows the user to search for restaurants in his/her present neighborhood, based on restaurants’ attributes (user requirement). – Automatically determines the user’s present location from the GSM network (functional requirement). – A request is handled in less than 2 seconds (quality attribute - performance) – Written in JAVA (constraint). – Restaurants data in Geography Markup Language 3.0 (external interface requirement). – Fully compliant with the EU privacy legislation (compliance to a business rule).

g

Business requirements for such a system are e.g.:
– Help a city visitor to find quickly a restaurant according to his/her preferences. – Get more customers for participating restaurants. – Create revenues for the service provider and the mobile operator.
6

University of Jyväskylä

Vision vs. scope
g

g

Product Vision – a long-term strategic concept of the ultimate purpose and form of a new system. Project Scope – the portion of the ultimate product vision that the current project will address. The scope draws the line boundary what is in and what is out for the current project.

Product Vision

Project Scope for release 1.0

Project Scope for release 1.1



Project Scope for release N

Wiegers, 2003

7

University of Jyväskylä

Project priorities
g

g

g

g

To enable effective decision making, stakeholders should agree on the project priorities. 5 main dimensions of a software project: features (scope), quality, schedule, cost, and staff. Those must be classified into one of the following categories: – Constraint – a limiting factor within which the project manager must operate. – Driver – a significant success objective with limited flexibility for adjustment. – Degree of freedom – a factor that the project manager has some latitude to adjust and balance against the other dimensions. The project manager can then to adjust, if needed, those factors that are degrees of freedom to achieve the project’s success drivers within the limits imposed by the constraints.
Wiegers, 2003

8

University of Jyväskylä

Project priorities (2)
Dimension
Schedule

Driver (state objective)
release 1.0 to be available by 10/1, release 1.1 by 12/1

Constraint (state limits)

Degree of Freedom (state allowable range)

Features

70-80% of high priority features must be included in release 1.0 90-95% of user acceptance tests must pass for release 1.0, 9598% for release 1.1 maximum team size is 6 developers + 4 testers budget overrun up to 15% acceptable without executive review
K. Wiegers

Quality

Staff

Cost

9

University of Jyväskylä

Project priorities (3)
g

In practice, often: – Features and schedule are drivers, staff and cost are constraints.. – .. quality is forced to be a degree of freedom.

© Juba - Juba Production Oy has decided to outsource production of this comic strip. - F.. Juba! - From now on, balloons will be typed by some communication agency from Kankaanpää. - And drawings will be made by some middlesize engineering office from Joensuu.

10

University of Jyväskylä

Vision and scope document
g g

Karl Wiegers’ web-site - http://www.processimpact.com/goodies.shtml The vision and scope document template and an example

11

University of Jyväskylä

Vision and scope document (2)
g

Wiegers’ proposition for the structure of the vision and scope document:
1. Business Requirements
1.1. Background 1.2. Business Opportunity 1.3. Business Objectives and Success Criteria 1.4. Customer or Market Needs 1.5. Business Risks

3. Scope and Limitations
3.1. Scope of Initial Release 3.2. Scope of Subsequent Releases 3.3. Limitations and Exclusions

4. Business Context
4.1. Stakeholder Profiles 4.2. Project Priorities 4.3. Operating Environment

2. Vision of the Solution
2.1. Vision Statement 2.2. Major Features 2.3. Assumptions and Dependencies

12

University of Jyväskylä

Recall: Bergman et al. formalism (Lecture 2)
“Objective” requirements - business (outer) “Constraining” requirements - inner

Bergman, King, and Lyytinen, 2002

13

University of Jyväskylä

1.1. Background
g

Provides a general description of the history or situation that leads to the recognition that this product should be built. Is a description of the current solution space (as in Bergman, King, and Lyytinen, 2002, see Lecture 2). Example:
A majority of Process Impact employees presently spend an average of 60 minutes per day going to the cafeteria to select, purchase, and eat lunch. About 20 minutes of this time is spent walking to and from the cafeteria, selecting their meals, and paying for their meals by cash or credit card. When employees go out for lunch, they spend an average of 90 minutes off-site. Some employees phone the cafeteria in advance to order a meal to be ready for them to pick up.

g

g

14

University of Jyväskylä

1.2. Business opportunity
g

Describes the market opportunity that exists or the business problem that is being solved. Identifies the problems that cannot currently be solved without the product. Is a description of the proposed problem space (as in Bergman, King, and Lyytinen, 2002). Example:
Working time is wasted. Also, employees don’t always get the selections they want because the cafeteria runs out of certain items. The cafeteria wastes a significant quantity of food that is not purchased and must be thrown away.

g

g

15

University of Jyväskylä

1.3. Business objectives and success criteria
g

Describes the important business objectives of the product in a way that is quantitative and measurable. Focuses on the value provided to the business. A part of business (outer) requirements, those relevant to business stakeholders. Example:
BO-1: Reduce cafeteria food wastage by 50% . BO-2: Reduce cafeteria operating costs by 15%. BO-3: Increase average effective work time by 20 minutes per employee per day. SC-1: Have 75% of those employees who presently use the cafeteria use the Cafeteria Ordering System within 6 months following initial release. – SC-2: Achieve an increase in the average rating on the quarterly cafeteria satisfaction survey of 0.5 within 3 months following initial release. – – – –

g

g

16

University of Jyväskylä

1.4. Customer or market needs
g

Describes the needs of typical customers or market segments, including needs that are not yet met by the marketplace or by existing systems. A part of outer (business) requirements, those relevant to users. Example:
– Employees request a system that would permit a cafeteria user to order meals online, to be delivered to a designated company location at a specified time and date. Such a system would save those employees who use the service considerable time and it would increase the chance of them getting the food items they prefer. – The future ability for employees to order meals for delivery from local restaurants would make a wider range of choices available to employees and provides the possibility of cost savings through volume purchase agreements with the restaurants.

g

g

17

University of Jyväskylä

1.5. Business risks
g

Summarizes the major business risks associated with developing this product, such as marketplace competition, timing issues, user acceptance, implementation issues, or possible negative impacts on the business. Analysis of potential conflicts between business requirements of different stakeholders. Example:
– – RI-1: The Cafeteria Employees Union might require that their contract be renegotiated to reflect the new employee roles and cafeteria hours of operation. (Probability = 0.6; Impact = 3). RI-2: Too few employees might use the system, reducing the return on investment from the system development and the changes in cafeteria operating procedures. (Probability =0.3; Impact = 9). RI-3: Local restaurants might not agree to offer price reductions to justify employees using the system, which would reduce employee satisfaction with the system and possibly their usage of it. (Probability = 0.4; Impact = 3). 18

g

g



University of Jyväskylä

2.1. Vision statement
g

Summarizes the purpose and intent of the new product and describes what the world will be like when it includes the product. Is an abstract description of the proposed solution space (as in Bergman, King, and Lyytinen, 2002). The following keyword template may be used:
– – – – – – – For [target user] Who [statement of the need or opportunity] The [product name] Is [a product category] That [key benefit, compelling reason to buy or use] Unlike [primary competing system, or current state of practice] Our product [statement of primary differentiation and advantages]
19

g

g

University of Jyväskylä

2.1. Vision statement (2)
g

Example: For employees who wish to order meals from the company cafeteria or from local restaurants on-line, the Cafeteria Ordering System is an Internetbased application that will accept individual or group meal orders, process payments, and trigger delivery of the prepared meals to a designated location on the Process Impact campus. Unlike the current telephone and manual ordering processes, employees who use the Cafeteria Ordering System will not have to go to the cafeteria to get their meals, which will save them time and will increase the food choices available to them.

20

University of Jyväskylä

2.2. Major features
g

A numbered list of the major features of the product, emphasizing those features that distinguish it from previous or competing products. Example:
– – – – – – – – – FE-1: Order meals from the cafeteria menu to be picked up or delivered FE-2: Order meals from local restaurants to be delivered FE-3: Create, view, modify, and delete meal service subscriptions FE-4: Register for meal payment options FE-5: Request meal delivery FE-6: Create, view, modify, and delete cafeteria menus FE-7: Order custom meals that aren’t on the cafeteria menu FE-8: Produce recipes and ingredient lists for custom meals from cafeteria FE-9: Provide system access through corporate Intranet or through outside Internet access by authorized employees

g

21

University of Jyväskylä

2.3. Assumptions and dependencies
g

Explicitly states assumptions that were made when conceiving the project. Note any major dependencies the project must rely upon for success, such as specific technologies, third-party vendors, development partners, or other business relationships. Similar to “business risks”, but about the inner requirements Example:
– AS-1: Intranet-enabled computers and printers will be available in the cafeteria to permit cafeteria employees to process the expected volume of orders without missing any delivery time windows. – AS-2: Cafeteria staff and vehicles will be available to deliver all orders within 15 minutes of the requested delivery time. – DE-1: If a restaurant has its own on-line ordering system, the Cafeteria Ordering System must be able to communicate with it bidirectionally.
22

g

g

University of Jyväskylä

All the components
1.1. Background 1.2. Business Opportunity 2.1. Vision Statement

1.3. Business Objectives 1.4. Customer Needs

2.2. Major Features

1.5. Business Risks

2.3. Assumptions
23

University of Jyväskylä

3. Scope and limitations
g

g

g

3.1. Scope of Initial Release - the intended major features that will be included in the initial release of the product 3.2. Scope of Subsequent Releases - if a staged evolution of the product is envisioned over time, describes which major features will be deferred to later releases. 3.3. Limitations and Exclusions - describes product features or characteristics that a stakeholder might anticipate, but which are not planned to be included in the new product. Example of limitations:
– LI-1: Some food items that are available from the cafeteria will not be suitable for delivery, so the menus available to patrons of the Cafeteria Ordering System will be a subset of the full cafeteria menus. – LI-2: The Cafeteria Ordering System shall be used only for the cafeteria at the main Process Impact campus in Clackamas, Oregon.
24

g

University of Jyväskylä

3. Scope and limitations (2)
Feature FE-1 Release 1 Standard meals from lunch menu only; delivery orders may be paid for only by payroll deduction Not implemented Implemented if time permits (medium priority) Register for payroll deduction payments only Meals will be delivered only to company campus sites Fully implemented Not implemented Not implemented Fully implemented 25 Not implemented Fully implemented Fully implemented Release 2 Accept orders also for breakfasts and dinners; accept credit and debit card payments Not implemented Fully implemented Register for credit card and debit card payments Add delivery from cafeteria to selected off-site locations Fully implemented Release 3

FE-2 FE-3 FE-4 FE-5

FE-6 FE-7 FE-8 FE-9

University of Jyväskylä

4.1. Stakeholder profiles
g

g

g

g

Attempts to identify all the different stakeholders for the product, and states their major interests in the product. For identification, orthogonal 3-dimensional framework (domain, system level, goal/means), discussed in Lecture 3, may be used. Then, for each identified stakeholder, the profile includes the major value or benefits they will receive from the product, their likely attitudes toward the product, major features and characteristics of interest, and any known constraints that must be accommodated. Example of a profile:
Stakeholder Users Major Value Better food selection; time savings; convenience Attitudes Strong enthusiasm, but might not use it as much as expected because of social value of eating lunches in cafeteria and restaurants Major Interests Simplicity of use; reliability of delivery; availability of food choices Constraints Access to corporate Intranet is needed

26

University of Jyväskylä

Other sections
g

4.2. Project Priorities – defines which of project dimensions are drivers, constraints, and degrees of freedom. Discussed earlier. 4.3. Operating Environment - describes the environment in which the system will be used.
– States requirements of “constraints” and “external interfaces” types, if any are known at this stage.

g

27

University of Jyväskylä

Scope management
g

Product vision is relatively static. It changes slowly as a product’s strategic positioning and business objectives evolve over time. In contrast, scope is more dynamic. It needs to be adjusted within existing schedule, budget, resource, and quality constraints. The customer’s idea about which features are more important also tends to change. Scope creep is undesirable. Scope creep is a condition in which the scope of the project continues to increase, typically in an uncontrolled fashion, throughout the development process. Therefore, explicit documentation of the project scope and scope management (i.e. making changes to the scope in a controlled way) are important.
28

g

g

g

University of Jyväskylä

Scope management (2)
Scope Initiation Scope Planning Scope Definition Scope Verification Scope Change Control
- selecting among possible alternative projects - writing the scope statement, e.g. in a vision and scope document - decomposition of the project into tasks sufficiently detailed for estimating required time, cost, resources - review and acceptance of the project scope

- as the project goes on, making changes to the scope in a controlled way
Schwalbe, 2003

29

University of Jyväskylä

Project selection
g

Different possible sets of features to implement may be seen as alternative projects – need to select one. In general, it is recommended to select projects with high benefit and low cost and risk. A Weighted Scoring Model (WSM) is a tool that allows systematic selection among projects based on multiple criteria:
– – – – – Identify criteria important to the project selection process, Assign weights (in percents) to each criterion so they add up to 100%, Assign scores to each criterion for each project, Multiply the scores by the weights and sum them up, The project with the highest total score wins.
Schwalbe, 2003

g

g

30

University of Jyväskylä

Project selection (2)

Schwalbe, 2003

31

University of Jyväskylä

Project decomposition
g

The Work Breakdown Structure (WBS) - an outcome-oriented analysis of the work involved in a project.
– Graphic portrayal of the project scope – Basis for planning and managing project schedules and costs

Schwalbe, 2003

32

University of Jyväskylä

Activity Sequencing
g g g

Needed for estimating the required time for completing the project Involves analysis of dependencies between activities Activity-on-Arrow (AOA) Network Diagram may be utilized for graphic representation

“A=1” means that activity A is going to take 1 day
Schwalbe, 2003

33

University of Jyväskylä

Lecture 4: Main points
g

RE, and a software/system development project as such, starts with defining business requirements, and a vision of the solution, consisting of set of features enabling satisfaction of those business requirements. Those are documented in the project’s vision and scope document. Vision and scope document should also include the stakeholders analysis and a definition of project priorities. Project scope is the portion of the ultimate product vision that the current project will address. Definition of the scope should be based on quantitative analysis (using e.g. WSM, WBS, AOA): implementation of which portion of the vision will be the most cost-effective, and whether it is possible to implement it under given constraints on schedule and budget.
34

g

g

g

University of Jyväskylä

Following next:
g

Requirements elicitation, including: Finding voice of users.. Interpreting users’ input.. Use Case analysis.. Wagner falls a victim to an overlooked exception in a use case..
© Juba

g

g

g

g

35

University of Jyväskylä

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close