Case Study: Import Utility

Susan: We have had a few requests from customers who want to be able to import their contact information from Outlook or Outlook Express into our site. Jack: So you want to integrate an import utility for contact information from external apps into our web site? Susan: Exactly, and I want your team on it.

Case Study: Import Utility

Jack: Hi team. Susan has asked us to develop a contact importer utility for the application, which is capable of handling data from Outlook, and Express. Carlos: Ive used Outlook contact data before. It can export into comma-separated value files, but the fields used by these applications are different. Jack: I guess we had better make it flexible to handle any kind of text input. Lets allow the user to configure separators, then let them map CSV field to our fields. Tanya: A good user interface principle would be to show them some of the data. Perhaps, once the separators are chosen, we could show a few lines of data for each field. Jack: I agree. Users are going to love how flexible this is. They could use it for contact information from several applications.

Case Study: Import Utility

(Two weeks later)

Susan: Jack, what is going on with that import application I asked you for two weeks ago? Jack: Weve examined the data formats, and have designed all of the user interfaces. We are about to start coding later today. Susan: You havent started coding yet!? Jack: We needed to plan for this application. If it is to import all sorts of contact information formats, and all of our 1.5 million users are going to see it, it has to be just right. Susan: I only asked for Outlook and Outlook Express. Just one of our partner companies has asked for it, with 40 users. Im pulling your team from the project and giving it to Rita. She said she could whip this up by Wednesday.

What went wrong here?

What went wrong here?

The team did not understand the customers requirements
Some information about the customers needs was not known to the team
There were only about 40 potential users Gold-plating the importer was not cost-effective

The team made some significant assumptions, which lead to greatly increased schedules
There were only 2 specific applications they needed to import from A fully customized import process is not justified

This is a failed project. Who is responsible?

Requirements provider (Susan)? Requirements gatherer (Jack)?

Bad Idea: Optimistic Requirements

Everyone feels the urge to impress
When someone asks us to build something, we want to build the best something ever
This is a very positive urge!

The problem is, those improvements may not be worth the extra time to the customer
Worse, the customer may no longer be interested

Customers like programs that have many features

However, they like these more:
Programs that work well The get it done attitude

Bad Idea: Gold-Plated Requirements

When documenting requirements, it is possible, even easy, to go too far
It is often unnecessary to write a 800 page volume describing every minor detail of the program
Each page with fancy diagrams and tables

You only need to document enough so that the team can understand what is required
Gold-plated requirements use up valuable project time Long requirements documents take longer for people to read Customers may not appreciate the extra time they have to spend helping you create the document

Bad Idea: Inadequate Requirements

A common problem in IT projects is inadequate requirements
The team gets started believing they know what the customer wants
This is dangerous, since often customers themselves dont know what they want, until you force them to think about it You may end up having to make changes to how features are implemented Worse, you may wind up with a program that no-one wants

Good Idea: Just Right Requirements

You want to find the right balance
If you need two people to carry your requirements document: Too much If your requirements document was written on a napkin or paper towel: Not enough Somewhere in the middle is the right amount

Your customers involvement is the key to success

The customer must agree that your document describes all the desired functions You must be convinced that the document is not vague, and does not use ambiguous language The customers time must be used effectively

Requirements
Requirements are what the customer wants
What functionality should the software provide? How should it work? What are the constraints? What are the details?

Requirements
Requirements Goals
The overall criteria that the customer wants to meet This normally comes from some business need

Objectives
A sub-goal

Deliverables
A real product to be developed by the team These should implement the goals and objectives

Success criteria
Descriptions of what the deliverables must be true for the project to be considered a success

Scope
General statements about the projects boundaries What should be part of the project? What should not be part of the project?

Why bother with requirements?

Poor requirements gathering can cause project failure
Incorrect assumptions can lead to the wrong software
This can lead to customer rejection

Low detail requirements can lead to short-cut implementations

This can lead to lack of customer acceptance This could require additional work to resolve the discrepancy

Low detail requirements can lead to gold-plating

This can lead to teams spending too long in development

Requirements Documents
Historically, a requirements document was a separate entity Modern requirements are put into a document which includes other relevant information
Our textbook describes a document called a project overview statement
This is a basic requirements document, used for obtaining approval for a project This document also includes risks and some other information

We will use a different requirements document, called a project scope document

This document describes all of the projects requirements and discusses the projects scope

Project Goals
Goals describe what your project is going to accomplish or produce
This will come directly from the customer Someone within the organization may need to clarify or disambiguate these goals
This is normally the analyst

e.g. The website will provide facilities to customers to buy and sell items at auction

Case Study: The Pathfinder 2.0 Project

Well examine case studies to demonstrate the course topics
note the project goal in bold

From: To: Subject: Hi Tyrone,

sherryb@afterburn.com tyronek@afterburn.com Proposal for a new pathfinder module

Some user studies and surveys indicate that customers are not satisfied with the pathfinding in our game engine. The board has agreed to consider a new project to create an improved pathfinder. I want you managing this project. The overview is below: PathFinder 2.0 will be an improved, human-like, pathfinding module for our game engine. Keep me posted, Sherry

Objectives
Objectives are statements which describe individual conditions to be met
e.g. The website will accept multiple forms of payment, including credit card and cheque

e.g. The website will provide a feedback system where sellers and buyers can make comments and rank each other after a transaction

Goals & Objectives

Goals and objectives should be SMART:
Specific: Goals & objectives should be specific, clear, & concise Measurable: You should be able to verify or measure the achievement of a goal or objective during development Accurate and Agreed To:
The goal/objective should be stated accurately, to avoid confusion Obtain consensus about goals/objectives from all key stakeholders

Realistic: Obviously impossible achievements are not appropriate goals or objectives Time Bound: You should specify a timeframe, as a duration or established end date for goals & objectives

Deliverables
Deliverables are the products of the project
This is not limited to software packages e.g. The deliverables for the Bug Tracker website will be:
Binary packages (.war) Source packages (.zip, .tar.gz) CD media & packaging Documentation (HTML) Demo video (Flash) Training videos (Flash) Administration panel plug-in Database adapters for Oracle, PostgreSQL, MySQL, DB2

Case Study: PathFinder 2.0

Deliverables:
New pathfinder module deployment Documentation on theory Statistical analysis of result (showing improvements) Full test suite

Exclusions from Scope

Exclusions from scope describe what will not be produced This is where you document what you do not plan to implement
This normally includes requirements that were wanted, not needed and were deferred to a later version You can also explicitly mention possible requests here that are outside the scope of this project

This document prevents you from having to justify rejecting change requests made later

Case Study: PathFinder 2.0

Exclusions from scope:
A web-based administration panel for viewing/altering state/data of the internal mechanism used to determine paths
This was deferred until version 2.1

Stakeholders
Here are the typical people involved with a project Project manager: Plans and oversees the project Program manager: Oversees many or all projects within the organization Customer: Provides initial requirements, periodic feedback, and approval of project upon completion Architect: Creates overall software structure, plans for implementing non-functional requirements (e.g. security), oversees development Analyst: Primary requirements gatherer Senior programmer: Participates in low-level design, uses design patterns and best practices, implements classes, unit tests Junior programmer: Implements methods and classes, maintains existing code, follows coding standards, unit tests Quality assurance team: Plans for acceptance and regression testing of all deliverables, performs testing, submits bug reports

Case Study: PathFinder 2.0

Stakeholders and responsibilities:
Project manager: Tyrone Campbell
Responsible for creating scope document, work breakdown structure, and schedule

Customer: Director of IT: Analyst:

Sherry Yeung Barb Heinz Jason Roloson

Responsible for approving all abovementioned documents Responsible for approving all abovementioned documents Responsible for defining requirements, which are input to scope document, and approving all abovementioned documents

Development lead: Erik Samuelsson

Responsible for approving schedule, and reviewing all remaining documents

Success Criteria
Success criteria are conditions which must be met in order for the project to be successful
Not all projects explicitly mention success criteria
e.g. The page load time must be less than 2 seconds for all of the websites pages e.g. Bug report files must be compatible with ABC Bug Traks BRF format. Report files can be exported to, and imported from, BRF files.

Assumptions
Every project involves a number of assumptions e.g. There will be an architect available by the start date e.g. The team will have adequate and functional computers during development These assumptions are generally safe to assume, provided you have done some preliminary investigation e.g. The architect is finishing up a project now, but she will be available next Tuesday e.g. All of the teams computers are less than 6 months old, according to the IT department Assumptions are often closely related to risks, which will be discussed later i.e. What happens if an assumption proves false?

Assumptions
You must document these assumptions Typical assumptions include: Key project members availability, skills, performance Vendor/contractor delivery times, performance Customer involvement and approvals If you document that a customer must be available for weekly meetings, and the customer signs off on it, then: The customer will have made a commitment If the customer claims to be unavailable, you can remind him/her that he/she signed off on that commitment If the customer does not make herself/himself available, you are not (fully) responsible for missing deadlines related to customer involvement

Case Study: PathFinder 2.0

Assumptions:
The AI development team will be available Gillian Kurose will be available for architecture The QA team will be available for a 3 week period A customer representative will be able to:
Supply sample paths which result in errors

Test the new module periodically, and provide feedback

Constraints
Constraints describe limitations of the project The most common three constraints are:
Time: Duration or closing dates Resources: Personnel and money Quality: Reliability, usability, etc.

Nearly all projects operate within all three constraints

However, projects will choose one as the primary constraint Presumably, the project manager will ensure this constraint is never compromised
Perhaps at the expense of violating the other constraints

e.g. A pharmaceutical project would put quality first, since insufficient quality can hurt or even kill people e.g. A competitive software project would typically put time first, since beating competitors to market is such an advantage
In contrast, open source projects typically put quality first

Constraints
Here are some other common constraints:
Executive and project team must be committed to the projects goals The project must be free from interruptions, company reorganizations, and financial setbacks Expectations must be realistic for the timeframe Expectations must be realistic for the skills required Skilled participants must be available for the project
This includes familiarity with new technologies

All stakeholders must be actively communicating

Case Study: PathFinder 2.0

Constraints:
The development team must not undertake any new projects or vacations for the duration of the proposed schedule The API for the module must be identical to the existing module The team must present a working model every 2 weeks to the customer for testing and feedback

Scope
The scope of a project defines its boundaries This is important to define which changes are reasonable, and which changes are not When a change request comes in that is within project scope, the project manager can decide whether or not it should be implemented When a change request comes in that is not within project scope, the project manager will normally reject the request e.g. This version of our investment tracking website is limited to mutual fund investments
A request for incorporating pension tracking would normally be rejected, with the scope document providing justification A request for incorporating a monthly earnings report for mutual funds could be accepted, if the schedule permits

Listening skills
Listening skills are critical for those gathering requirements Passive listening
Let the customer tell you what they want You are not really listening effectively when you: Have a tough time understanding what people are trying to say Start thinking about how you are going to respond, before the customer has finished talking Have a tough time not hijacking the conversation yourself

Active listening
Active listening involves following up on what you hear Some people repeat (in their own words) what they believe the customer has said A requirements gatherer may follow up a comment with a question for more detail This may involve a specific suggestion

Requirements Gathering
Typically, customers will start with high-level requirements
It is often necessary to:
Ask the customer for more detail Come up with specific ideas, and ask the customer for feedback

Requirements can be gathered using the following methods:

Customer interviews Questionnaires Passive observing

Requirements Gathering
Customers will often ask for too many features
These features might not be possible within the desired schedule A good project manager will first separate wants from needs Ask customers what the minimal conditions are for success Ask customers why a feature is a need, not a want Some of the wants might have to be delayed until a later version to meet the schedule Remember, you can say no if you explain that including a feature will result in later schedules

It is necessary to get as much detail as possible, so that an accurate estimate of work required is possible
If you dont ask for the detail, you will have to get it somehow If you wait until later, your estimates may have been inaccurate