WHAT ARE REQUIREMENTS FOR?

Transcription

1 WHAT ARE REQUIREMENTS FOR? Previously on CS4566/CS Business rules Business events Business processes And now.. Business Models Week 11 1

2 The Business as a source of requirements the bank the factory the hospital the university the bus company the health service the railway service But what happens if the business itself is a software business? So, the product is just a computer program? A set of instructions for a computer A combination of computer instructions and data definitions that enable computer hardware to perform computational or control functions (IEEE Std ) The trouble with this perspective? Week 11 2

3 What s a computer program/system? The point of the product is to provide value to the stakeholders. Business Models Another aspect of the requirements context. A Business Model describes the Rationale of how an Organization Creates Delivers and Captures Value. Week 11 3

4 Business Model Canvas A framework for representing Business Models developed by Alexander Osterwalder 9 different building blocks account for Variations in how different organizations Create, Deliver and Capture Value Accounts for the differences and similarities between companies and explains why newer companies are different from what went before. Nine building blocks of the Business Model Canvas: 1. Customer Segments 2. Customer Relationships 3. Channels 4. Value Propositions 5. Key Resources 6. Key Activities 7. Key Partnerships 8. Cost Structure and 9. Revenue Streams Week 11 4

5 Layout of the BM Canvas Value propositions are central Cost Structure and Revenue Streams at the bottom Customer-side components on the right Resources and activities on the left. Layout of the Canvas Week 11 5

6 Different types of goods/services Physical goods (physical products durable and nondurable) Intangible goods (software and intellectual property) Human services (people s time and effort) Financial goods (cash and other assets) Different types of goods/services Are associated with different types of revenue streams. Week 11 6

7 Revenue streams Selling (physical or non-physical) products Charging a fee for a service on a per use basis Subscription charging a regular amount for a continuous service Lending/Leasing/Renting - exclusive right to the use of a physical asset for a particular period of time. Licensing - charging for the use of a protected intellectual property Brokerage/commission fees - Revenue from providing an intermediate service between 2 parties. How AirB&B makes its money Advertising - Revenue generated from charging fees for product advertising Facebook, Google while giving free services or products to target (what?) The Value Propositions The essential requirement(s) All other requirements such as those relating to security, data collection, etc. are there to support the creation of value, the delivery of value to the customers and/or the capture of value by the company that created it. Week 11 7

8 Creating value: User Stories Represent functionality that will be valued by users Three aspects: 1. Brief description of story used for planning/reminding 2. Conversations about the story to fill out details 3. Tests that convey and document details can be used to determine when a story is complete Each story is written on a story card. Suitable for sorting and sifting. Examples of specifying the value to users Good: A user can search for jobs A company can post new jobs No good: The software will be written in C++ The program will connect to the database through a connection pool In fact, quality requirements are generally ignored at this stage. (Dealt with in design.) Week 11 8

9 Or, as Karl Cox says: Accept this at your peril. An example: The staff meeting minutes must be distributed to staff within an hour of closing of the meeting. Writing Stories Customer on the Agile team writes stories Written in the language of the business To allow prioritization Customer is primary product visionary Good stories are Independent Negotiable Valuable to users Estimatable Small Testable Week 11 9

10 Sizing stories Too broad = impossible to test/code Too narrow = not useful functionality Many teams aim for a test & code cycle of between 4 hours and 2 weeks With one or two programmers per story Split long stories ( epics ) into smaller pieces Rather than specify details, they rely on conversations with the customer Big stories can serve as placeholders for areas of the system that still need to be discussed. Independent Relationships between stories are not documented anywhere Stories that depend on other stories are difficult to prioritize and estimate Examples for a company like Monster.ie: An employer can pay for a job posting with a Visa card. A company can pay for a job posting with a Mastercard. An advertiser can pay for a job posting with an American Express card. Week 11 10

11 User Stories are always Negotiable Story cards serve as reminders not contracts Details need to be fleshed out in conversation Story cards should have a phrase or sentence to serve as reminder to have conversations. Valuable Both to the people using the software and the people paying for the software Avoid stories valued only by developers Rewrite them to make the benefits to customers/users apparent Example All connections to the database are through a connection pool could be rewritten as Up to 50 users are able to use the application with a 5-user database license Week 11 11

12 Advantages of user stories Emphasize verbal communication Comprehensible by everyone Work for iterative development Encourage deferring detail Support opportunistic development Encourage participatory design. Disadvantages of User Stories Stories are too small Interdependent stories are not documented as such Too many stories How to prioritise? No traceability Not suitable in some important types of requirements situations. Week 11 12