2. Introduction of Speaker
Sheraz Pervaiz
BS from Canada in Computer Science
MS from Germany in Software Technology
Almost 14 years of Experience
Working as Engineering Manager at Coeus Gmbh in Lahore Office
Worked as Consultant , Project Manager and different roles in different Software
Houses in Pakistan / Germany
Worked in Government Sector to provide consultancy to World Bank Funded
Projects
Has been associated with different Universities in different roles from Assistant
Professor to Associate Professor
Recorded lectures for Virtual University for MS Program - Software Design Course
5. Motivation Continue
Annual Chaos Report – 10th Edition by Cavendish Group
One of the Top Three Reasons for Project Failure is :
Ambiguous Requirements Specifications
Success of Software Projects increases to more than 100%
to 34% from 2004 due to smaller iteration of phase with
more focus on Requirement Management
7. Myth# 1: Client know Everything
This seems counterintuitive.
Customers tend to talk about features, not what they truly need
People often don’t know what they want.
8. Myth # 1: Example
Client Say:
I need a software which will allow me to select multiple options at one time
and I need RadioButton ??
What PM will say:
Either he can accept or better ask for what client want to do
Client usually tell the Solution not the Requirement
9. Myth # 2: Now we know Client want
Scenario:
Let's say a software system is being developed that will manage recipes. After the first
client meeting to discuss the software specification, the following requirements are
identified :
i. The software shall have a simple user interface to enter recipes.
ii. The software shall make it easy to find recipes.
Project Manager: Happy that we got what we want from client
10. Myth # # 2: continue
Ambiguities:
The software shall have a simple user interface to enter
recipes:
What qualifies to be simpler User Interface ? Is it Textbox, images only…
The software shall make it easy to find recipes ?
What is easy to find recipes?
12. Myth # 3: Requirements are Fixed
While Project is underway new changes are requested leading to
Change Request – Scope Creep and this is Normal
At time what we deliver in the end is totally opposite what we make
as prototype – Throwaway Prototype
Top 10 Obstacles to Project Success by 2010 Global Survey
Example:
You have a shopping list – a contract/agreement
You come back with items not on the list – Requirements are Changed
13. Myth # 3: Requirements are Fixed
Client:
After Client demo, client said there should be a new button on GUI where I can
add new images and Software should tell me how much similar images are there already in
the System.
Traps: What is criteria of Similar Images ?
Client: Well I don’t know yet but I am paying you for this
Estimates by Dev Team: 80 hr ( 2 Weeks ) with expected variation of 30-40%
Client: Why Its taking so much time, I have just asked for a simple button, last time I ask for
a button it took only 4 hrs ….
Dev Team: Well it depend on functionality of GUI button
14. Myth # 4: Assumption
No need to write more as it is already assumed to be understood
Well then every-one can have different understanding
Well “Assumption is mother of all Disaster”
15. Myth # 4: Lets go with Non-Technical
One
The first article under Section 8 - Powers of Congress:
The Congress shall have Power To lay and collect Taxes, Duties, Imposts and Excises, to pay the
Debts and provide for the common Defense and general Welfare of the United States; but all
Duties, Imposts and Excises shall be uniform throughout the United States;
Problems:
How we determine what is done in general welfare of United State? Health /Education/Law ??
16. Myth # 5: One Solution Fit For All
There will be a magical keyword which will take care of all of the remaining
requirements
.
Usually create problem with Non-Functional Requirements
For Example:
The software should have minimum loading time ?
The color of the GUI should be combination of blue, grey and etc
17. Myth # 6: What is Good Requirement
How much detail is required ?
It depend who is doing the
Don' t expect: Best written requirements can replace dialogue
Customer give solution not need
18. Myth # 6: Example
First Version:
When alarm system is armed and sensor is triggered the user shall be able to
entered numeric password to disarm the system- Requirement
Second Version: The system shall give audible tone after the user enter 8-
Digit password - Requirement and stringent design
Fourth: The system shall sound at 1000 Hz and at a tone of 75db and for 0.5
second after user enter 8-digit password - Design
19. Roadmap
Myths in Software Requirement – Part Two – Tentatively in Mid - May
Focus: Handling Requirement Myths
Myths in Software Requirement – Part Three – Tentatively in Mid-June
Focus: Requirement Myths and Project Management