Problem Statement

Software Engineering II - Exercise

Bernd Bruegge Helmut Naughton

Applied Software Engineering Technische Universitaet Muenchen

http://wwwbrugge.in.tum.de

May 6

2009

Problem Statement

Some organizational things

•  Date for the final exam

•  Wednesday, August 5th 2009 Place: MW 1350

Time: 8.30 - 10.30

•  Trying to reschedule to July 30^th in the afternoon

•  The lecture on May 12th will take place as usual (contrary to the tentative timetable)

•  Subject will again be testing

Comments on the SPMP assignment

•  The focus of this exercise is on understanding and getting familiar with

•  The structure of an SPMP

•  The content creation process

•  Positioning of SPMP within the project lifecycle

•  Quality is more important than raw quantity

•  There is no minimum or maximum page count

•  If something does not make sense for your chosen project or you really cannot find any information then

enter “not applicable” or “to be done” in the SPMP section

•  Some sections make sense and can be meaningfully filled for any type of project – these are of high value

•  The aim is to produce a document that is in itself

consistent and also in line with the project.

Comments on the SPMP assignment

•  If you base your SPMP on a real-world project, make sure to

•  Try to recreate the circumstances the project was conducted in and learn from them (“Archaeologist”)

•  Write the SPMP as if you were competing for the contract and had to write a better plan than your competition (“Entrepreneur”)

•  The second aspect is also true for projects which are not based on a real-world counterpart

•  Write the SPMP as if you are trying to convince a

potential customer to award you the contract.

Comments on the SPMP assignment

•  A quick reminder of the parameters:

•  You can work in teams with up to 6 participants

•  Submission date is July 1^st 2009, 2PM

•  Oral presentation of these plans on July 1^st 2009 in the exercise session

•  Completing the SPMP assignment is part of the

exercises and therefore required for taking part in the final exam

•  Excellent solutions and presentations will also be reflected in the final grade

Outline

•  Problem Statement

•  Functional Requirements

•  Nonfunctional Requirements

•  User Interface

•  Object Model

•  System Decomposition

•  Deployment

Problem Statement

•  The problem statement is developed as a

description of the problem addressed by the system

•  A problem statement describes

•  The current situation

•  The objectives

•  The functionality the new system should support

•  The environment in which the system will be deployed

•  Deliverables expected by the client

•  Delivery dates

•  A set of acceptance criteria.

Problem Statement

•  When do we write the problem statement?

•  Before the project kickoff

•  What purpose does the problem statement serve?

•  Better understand the scope and parameters of the project

•  Parts of the problem statement serve as seed for

•  A first draft of the project plan itself (SPMP)

•  The requirements analysis document (RAD, “Lastenheft”)

•  The system design document (SDD)

•  The object design document (ODD)

•  Who writes the problem statement?

•  Plan A: The customer

•  Plan B: The customer and the project manager Plan C: You

Comparison: Lastenheft - Pflichtenheft

•  Lastenheft: DIN 69905-VDI/VDE 3694 - VDA 6.1:

Gesamtheit der Forderungen des Auftraggebers an die Lieferungen und Leistungen eines

Auftragnehmers.

•  Pflichtenheft: DIN 69905-VDI/VDE 3694 - VDA 6.1:

Vom Auftragnehmer erarbeitetes

Realisierungsvorhaben aufgrund der Umsetzung des Lastenheftes.

How do these terms map to our documents from

the textbook? (see german translation p. 178.)

How do these terms map to internationally used

concepts?

Standards for requirement specification

•  Is there an international standard for it?

•  IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications

•  This standard combines both documents into

one and is common for many software projects

NASA has its own concepts

•  How does NASA do it?

•  Two parts:

“system requirements” and “design-to specification”

•  The first is written by the client and contains mission requirements and basic parameters

(e.g. http://mars.jpl.nasa.gov/mgs/scsys/e3/e30.html for the Global Mars Surveyer)

•  The second is written by the contractor and specifies the chosen design

•  Correspondence between NASA documents and documents used in the textbook

•  „system requirements” → RAD (requirements analysis document)

•  “design-to specification” → SDD (system design document)

maybe even including parts of the ODD (object design document)

Ingredients of a Problem Statement

1.  Current situation

•  The problem to be solved

•  Description of one or more scenarios

2.  Objectives

3.  Requirements

•  Functional and nonfunctional requirements

•  Constraints (“pseudo requirements”)

4.  Target environment

•  The environment in which the delivered system has to perform a specified set of system tests

5.  Project schedule

•  Major milestones including deadline for delivery

6.  Client acceptance criteria

•  Criteria for the system tests.

Current situation: The problem to be solved

•  There is a problem in the current situation

•  Examples:

•  The response time when playing chess is too slow.

•  I want to play Go, but cannot find players on my level.

•  What has changed? Why can address the problem now?

•  Change in the application domain

•  A new function (business process) is introduced into the business

•  Change in the solution domain

•  A new solution (technology enabler) has appeared

ARENA: The Current Situation

•  The Internet has enabled virtual communities

•  Multi-player computer games now include support for virtual communities

•  Players can receive news about game upgrades, new game levels, announcement of matches and scores

•  Currently each game company develops such community support in each individual game

•  Each company uses a different infrastructure, different concepts, and provides different levels of support

•  This redundancy leads to problems:

•  High learning curve for players joining a community

•  Game companies develop the support from scratch

•  Advertisers contact each community separately.

ARENA: The Objectives

•  Provide a generic infrastructure to

•  Support virtual game communities.

•  Register new games

•  Register new players

•  Organize tournaments

•  Keeping track of the players scores.

•  Provide a framework for tournament organizers

•  to customize the number and sequence of matchers and the accumulation of expert rating points.

•  Provide a framework for game developers

•  for developing new games, or for adapting existing games into the ARENA framework.

•  Provide an infrastructure for advertisers.

ARENA: The Objectives (2)

•  Provide a framework for tournament organizers

•  to customize the number and sequence of matchers and the accumulation of expert rating points

•  Provide a framework for game developers

•  for developing new games, or for adapting existing games into the ARENA framework

•  Provide an infrastructure for

advertisers.

ARENA Functional Requirements

•  Players must be able to register for and play their favorite games

•  Spectators must be able to watch matches in progress without prior registration and without prior

knowledge of the match

•  The operator must be able to add new

games.

ARENA Nonfunctional Requirements

•  The system must support

•  10 parallel tournaments,

•  Each involving up to 64 players

•  and several hundreds of spectators.

•  The ARENA server must be available 24 hours a day

•  The operator must be able to add new games without modifications to the existing system

•  ARENA must be able to dynamically interface to existing games provided by other game

developers.

Constraints

•  Constraint: Any client restriction on the solution domain and project management

•  Sometimes also called Pseudo Requirements

•  Constraints restrict the solution space

•  Example of constraints

•  Delivery constraints (“must be delivered before Christmas”)

•  Organizational constraints (“must have a separate testing team”)

•  Implementation constraints (“must be written in Cobol”)

•  Target platform constraints (“must run on Windows 98”)

ARENA Target Environment

Example:

•  Users must be able to run ARENA games as applets in any Web Browser

•  The web page must be validated through the W3C Markup Validation Service

•  Interaction with the ARENA Server must be via HTTP/1.1.

To be distinguished from development environment

•  “Prototypes will be built with Revolution 2.6.1”

•  “Games will be tested with Internet Explorer and Firefox”

•  “The implementation language will be Java 1.6”

•  “The IDE will be Eclipse 3.5”

Project Schedule

•  The project schedule is an optional part of the problem statement

•  Managerial information

•  Often the seed for the schedule in the software project management plan.

•  Lists only major milestones negotiated with the client

•  3 to 4 dates (fixed dates!)

•  Example:

•  Project-kickoff April 15

•  System review May 15

•  Review of first prototype Jun 10

•  Client acceptance test July 30

Client Acceptance Criteria

•  The system supports 10 parallel tournaments with 64 players and 10 spectators per

tournament

•  The client supports the games Tic-Tac-Toe and Asteroids

•  The average response time for a command issued by a client is less than 10 msec

•  The average up-time of the ARENA server during

one week of testing is 95%.

Reflections on the OWL problem statement

•  Pro

•  You can get the basic idea of the project quickly

•  Con

•  Probably better not include object diagram

•  Not enough specifics, constraints

•  No short abstract

•  No (rough) time plan

•  Team structure does not need to be in here

•  In parts maybe already too specific

•  No explicit mention of deliverables

Further steps

•  Subsystem Decomposition

•  Object Model

•  Test configuration

•  User Interface of Client

•  User Interface of Server

ARENA Subsystem Decomposition

Tournament

Component Management

User Management

Tournament

User Directory

User Interface

Session Advertisement

ARENA Object Model (application domain)

Tournament League Game

Tournament Style

Player

Round

Match

KOStyle RoundRobin

ARENA Object Model (with solution domain objects)

Tournament League Game

TournamentStyle

Player

Round Match TicTacToe

Asteroids

KOStyle RoundRobin

Move

MatchPanel

Configuration for Client Acceptance Test

(Instance-Diagram)

ARENA User Interface (Client)

ARENA User Interface (Server)

More Information on ARENA

•  The ARENA Website:

http://sysiphus.in.tum.de/arena

•  The ARENA case study is described at the end of each chapter of the textbook, starting with Chapter 4.

•  Read Chapter 4.6

Research and Access to Publications

•  Most online publications (IEEE, ACM) are only available for a fee

•  TUM students can use the DocumentWeb service provided by the LRZ

•  http://docweb.lrz-muenchen.de/

•  Login with your mytum account

•  Alternatively

•  Proxy: http://proxy.biblio.tu-muenchen.de Port: 8080

•  Only usable in Garching or via VPN

Research and Access to Publications

•  Useful search tools:

•  http://ieeexplore.ieee.org/search/advsearch.jsp

•  http://portal.acm.org/results.cfm

•  http://scholar.google.com

•  http://citeseerx.ist.psu.edu

•  Collect, manage, and cite your research sources:

•  http://www.zotero.org

•  http://www.endnote.com