1. Myths in Software
Requirements
Part One

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

3. Agenda
 Motivation
 Myth # 1
 Myth # 2
 Myth # 3
 Myth # 4
 Myth # 5
 Myth # 6
 Future Roadmap
 Q&A

4. Motivation

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

6. Standish Report: Project Success Factors

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?

11. Myth # 3: Requirements are fixed

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

20. Q & A