Requirement Management for IFDK

Material For Software Testing

Course – Day3

Features & Requirements

Marko ”NarsuMan” Rintamäki

2011

Our focus system IFDK

Requirement Management

What means Requirement Manangement?

What means a feature, requirement, use cases,

and user story

Different points of view on IFDK system

Seller

User

Developer

Scalability

Stability

Performance

Security

Performance

Stress

Usabilty

Different points of view on system Requirement Category‘s

Requirements from product development point of view

„scalability“ „scalability“

„Stability“

„Functionality“

Requirement Management continues…

Between 40% and 60% of software failures and defects are the result of poor software management and requirements definition. In plain English, this means that about half of the problems encountered could have been avoided by making it clear, from the very beginning, what the customer expected from the respective project. This is to say that the programming was fine and the developers did their job well – only they did a different job from what they were supposed to. http://www.softwareprojects.org Read also http://www.projectshrink.com/why-requirements-change-270.html

http://www.softwareprojects.org/

How to find requirements?

● You can find requirements from several sources: Users, Stakeholders,

Business and Development team and many others

● Requirements are trying to define nature of feature/system/solution

more specific than common written document does. This information

is helping development team to design a solution for a need

● There is several common methods to define and gather requirements.

– Traditional Requirement modeling (http://en.wikipedia.org/wiki/Requirements_management)

– RUP/UML based Use Case modeling (http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process)

– Agile XP oriented User Story’s (http://en.wikipedia.org/wiki/Agile_software_development)

● Your task is to figure out a small difference between them

Read more http://en.wikipedia.org/wiki/Requirements_management

System Testing

Integration Testing

Unit Testing

Customer Requirements

System Requirements

Design Requirements

Component Requirements

Acceptance Testing

Why we need requirements from testing point of view?

Implementation

„Developer's Area“

„Test Engineers Area“

”Traditional Testing Levels”

Feature

Feature

Feature is functionality of product/software which can be seen as one module of whole product Internal Flame kit has WLAN support Internal Flame Kit has touch screen user interface

Do some googling!! Create a wiki page!! AboutUserStory

Idea#1

Who is defining a Feature?

Customer

I would like to have Internal Flame Drum Kit

Could you deliver it to us?

Actually We have several features for it here

Ok! What's a plan

Nice looking feature propoals. We have to do some evaluation

Idea#2

Idea#3

Idea#4

Idea#1

-Technology? -Knowledge -Resource -Solution? -Priority?

Is product a combination of features?

Calory Counter

Drum Metronome

Table Drum Mode

Standby Mode

MIDI Support

Touch Screen with single tap

Core Software

Is product a combination of features?

Calory Counter

Drum Metronome

Table Drum Mode Standby Mode

MIDI Support


Practice: Defining Features

Play problem domain

card game with team to

search for features?

Feature X * n

Feature example 1 (Invented on course 2009-2010)

Calory Counter:

Player can measure calories during training session. This can be

seen as exercise result in web service eg. Facebook application

Energy usage

Feature example 2 (Invented on course 2009-2010)

Table Drummer:

Player drums table board instead of drum can. IFDK kit is able to

use DSP algorithm to detect correct drum sound from environment.

In training mode IFDK is trained to detect drum sounds for

environment.

Table Drum Mode

DSP Algorithm

Customer/Business Requirements?

Calory Counter Drum Metronome

Table Drum Mode

Simple Training Mode

MIDI Support


Customer Type 1 Customer Type 2 Customer Type 3 Customer Type 4

Who are our target customers?

Customer Strategy

Drum Metronome Table Drum Mode

Simple Training Mode

MIDI Support


Customer Type 1 Customer Type 2 Customer Type 3 Customer Type 4

What is our key customer?

Primary Target

Calory Counter

Secondary Target

Requirement

Requirement

Requirement USE CASE #2

USE CASE #1

USE CASE #3

Requirement

Requirement

Requirement

USE CASE #1 User Story #1

User Story #2

User Story #3

Requirement


USE CASE #1

USE CASE #3

Requirement USE CASE #1 User Story #1

Requirement

Requirement


USE CASE #1

USE CASE #3

Requirement

Requirement

Requirement


User Story #2

User Story #3

Requirement

Requirement


USE CASE #1

USE CASE #3

Requirement

Requirement

Requirement


User Story #2

User Story #3

Requirement

Requirement


USE CASE #1

USE CASE #3

Requirement

Requirement

Requirement

USE CASE #1

Requirement


USE CASE #1 Requirement

Requirement

USE CASE #1

Features and release planning

Release 0.1

Release 1.1 Release 1.2

Feature: Simple Training Mode

Feature: Table Drum mode

Feature Touch Screen with single tap

Release 1.0

TIME TO MARKET!! For Target Group 3

CORE/Platform Software Development



Defines

Feature X * n

Functional Requirements

Non-Functional Requirements

Use Cases

Vision of

product

Simple Requirement Management Process

Problem Domain

Solution Domain

Solution Proposal

Customer/Marketing/business

User Storys

FEATURE

VISION/NEED/PROPOSAL

YOU!

Design documents & implementation

Test Case

Traditional Requirement Modeling

• A requirement shall be a complete sentence. • Sentence has to be understandable, measurable and

testable

• ReqId1 - Tractor has four wheels • ReqId2 - Tractor has one exhaust pipe • ReqId3 - Engine of tractor is capable of use flexi fuel • ReqId4 – The tractor has a hook for trailer • ReqId5- The tractor shall have a enhanced driving system

Google: requirement specification template and SRS Software Requirement Specification

Functional and non-functional requirements



Functional Requirement

"User can select application from ui

by using wheel button”

”Tractor can be driven both directions”

Non-Functional Requirement

"Performance Requirement"

”Tractor Startup should take

minimum 10 seconds”

”Usability Requirement”

”User interface should be able to control using simple wheel quide”

”The hook can last max 20Kkg

trailer load”

How it works? How fast it is? How stable it is?


Functional

Requirements

Non-Functional

Requirements

Functionality

Stability

Security

Performance

Usability

User Interface Design?

Feature X

Traditional Requirement Modelling and Features

.......

Practice: Define traditional requirements for you

feature



Non-Functional Requirement category examples

Scalability

How our implementation is scaling in situation X?

Stability

Is our implementation stable on situation like

zzzZZZ?

Functionality

Implementation should work like this way

Security

Is our implementation secure enough against

attack type xxx?

Performance How good performance our implementation provides

against competitor?

Stress How much we can stress

our implentation without a problems?

Usabilty Is implementation usable for target

customer?

Maintenance Is implementation easy to maintain?

Defines

Feature X * n



Use Cases

Vision of

product


Problem Domain

Solution Domain

Solution Proposal

Customer User Storys

FEATURE


YOU!


Test Case

Use Case

USE CASE

Written scenario for action. Also execeptions included

Use Case: Open Application

Actor: IFDK User

Step1: Gadget User touches home button

Step2: UI wakeup initiated (if standby)

Step3: Home screen is activated

Setp4: User browses applications specific icons using wheel button

Step5. Icons are moving on screen left and right

Step6: User selects application by pushing wheel button

Step7: Application starts up <4 seconds

Execptions:

1. If application cannot start there will be note on screen about problem

Use Cases

Use Case

A use case in software engineering and systems engineering, is a description of steps or actions between a user (or "actor") and a software system which leads the user towards something useful.[1]

Wikipedia

http://en.wikipedia.org/wiki/Software_engineering

http://en.wikipedia.org/wiki/Software_engineering

http://en.wikipedia.org/wiki/Systems_engineering

http://en.wikipedia.org/wiki/Systems_engineering

http://en.wikipedia.org/wiki/Actor_(UML)

http://en.wikipedia.org/wiki/Use_case

Practice: Create Use Cases

ACTOR

Use Case

SYSTEM Actor: Player System: IFDK kit UC Scenario: Standby mode after boot 1. User turn’s on IFDK by pressing

red button on front panel 2. Screen wil flash and show

welcome text ”Hello my friend!” 3. User interface opens after

seconds 4. Screen will show three selection

buttons 5. After 30 seconds user inteface

goes to standby mode

Exeption: If user activates screenby tapping it standby counter will be reseted

Defines

Feature X * n



Use Cases

Vision of

product


Problem Domain

Solution Domain

Solution Proposal

Customer User Storys

FEATURE


YOU!


Test Case

User Story

USER STORY

Simple phrase describes a need. This can lead to several other storys!

"As user I would like to open application easily"

"As a user I would like to use

wheel for simplify ui interaction"

"As a user I would like to initate application fast enough"

"As a tractor driver I would like to have enhanced driving system”

User Story


Agile Requirement Management

Epic Story

User Story

UserStory0001

UserStory0002

UserStory0003

EpicStory0001

As a user I would like to

use product Which is fast to

power on

As a Customer I would like to have top quality product

Gadget should have >30fps

UI performace

Gadget should Startup <5seconds

Practice: Create User Storys

USER STORY: As a bad behavin person I cannot access IFDK using wlan without encryption How to test? Acceptance Criteria?

USER STORY: As a member of audience I can hear effect sound that player is having electrical shocks How to test? Acceptance Criteria?

Use Case, User Story, Requirement

USE CASE

Written scenario for action. Also execeptions

included

Use Case: Open Application

Actor: Gadget User

Step1: Gadget User touches home button

Step2: UI wakeup initiated (if standby)

Step3: Home screen is activated

Setp4: User browses applications specific icons

using wheel button

Step5. Icons are moving on screen left and right

Step6: User selects application by pushing wheel

button

Step7: Application starts up <4 seconds

Execptions:

1. If application cannot start there will be note on

screen about problem

USER STORY

Simple phrase describes a need. This can lead to several other storys!

"As user I would like to open application easily"

"As a user I would like to use wheel for simplify ui

interaction"

"As a user I would like to initate application fast

enough"

Non Functional Requirement

"Performance Requirement"

"Application Startup should take minimum 4 seconds"

Functional Requirement

"User can select application from ui

by using wheel button"

Requirement Measurable

Testable

Education

Requirement Management for IFDK