system level requirements gathering and analysis

www.wgconsulting.com
Requirements Gathering:
The first step to project
success
Lecture 1
BSIT-6th

Copyright 2014, WG Consulting, LLC 33/15/2016
 70% of organizations have suffered at least one project failure in the prior 12 months.
 50% of respondents also indicated that their project failed to consistently achieve
what they set out to achieve!
 Many organizations fail to measure benefits so they are unaware of their true status
in terms of benefits realization (success assessment).
Source: KPMG Study, Global IT Management Survey
Dec 2010
The Facts

 Interviews with 600 people closely involved in software development projects find that
even at the start of a project many people expect their projects to fail! (a survey)
 “Fuzzy business objectives, out-of-sync stakeholders, and excessive rework” mean that
75% of project participants lack confidence that their projects will succeed.
 78% of respondents reported that the “Business is usually or always out of sync with
project requirements” (a survey)
What are the statistics?

 Too many project managers either overlook the importance of requirements
management or fail to understand the difference between scope, requirements, and
expectations.
 Scope = draws boundary b/w what’s in and what’s out of the projecct.
 In fact, 60-80 percent of project failures can be attributed directly to poor requirements
gathering, analysis, and management.
G. Chandrashekar of the ProjectSmart blog wrote,
“Innumerable studies have shown that requirements gathering is the single most important
step…It’s far more expensive to fix a requirements error than a coding error. But somehow
everyone seems to believe that a requirements specification document is the easiest part to
produce…It can’t be further from the truth. No one ever built a good structure without the
right foundation. Make sure that you take time to gather the requirements fully and analyze
them in depth.”
What is the problem?

Why Projects Fail….

 The requirements gathering or the discovery phase is essential to the
success of any project.
 Many experienced project managers would agree that if the
requirements are identified correctly and early in the project cycle there
would be a significant reduction in the project budget.
 If an effort to save time and project dollars, requirements gathering is
often overlooked or is not allocated enough time or budget.
Why are requirements important?

Five key components of requirements gathering
1. Gathering requirements comes first, defining scope comes second.
It is fairly common in the project management world for people to use
the terms “requirements” and “scope” synonymously. But they are
different. “Requirements” define what is needed and “Scope” is how you
are going get there.
 “Requirements” are the demands, needs, and specifications for a
product as outlined by project stakeholders. The Deep Fried Brain
Blog defines requirements as what the customer needs.
 “Scope” is defined as the work that needs to be accomplished to
deliver a product, service, or result with the specified features and
functions.

2. There are two types of requirements: project requirements and
product requirements.
Project Requirements define how the work will be managed. Project
requirements focus on who, when, where, and how something gets
done.
Product Requirements include high level features or capabilities that the
business team has committed to delivering to a customer.
Project requirements must be defined first and then products evaluated
based on the best fit to these needs.

3. Make sure you adequately document all the requirements.
The requirements gathering process should be iterative and all discussions
documented and verified to make sure requirements were understood
correctly.
Requirements should be evaluated throughout the project to make sure
systems are not overly complicated, over designed and address the initial
needs defined at the beginning of the project.

4. Select the best methodology for the project.
The approach when developing a project must be determined for each
engagement based on the project team, the organization and the goals of
the project. In some cases, a hybrid of these methodologies is ideal.
A few examples of project methodology include:
RAD (Rapid Application Deployment) Spiral
• Used for less structured projects
• Projects are divided to smaller
initiatives
• Prototyping is used
Spiral
• Incremental build
• Additional functionality added later
• Prototyping used
Waterfall
• Tightly defined objectives
• Controlled process
• Major milestones with accountability
JAD (Joint Application Design)
• Involves the client or end user in the
design and development of an
application
• Collaborative workshops
• Requires dedicated resources
Scrum
• Flexible and collaborative
• General guidelines are set but
constantly reevaluated
• Inspect and reevaluate

5. Engage a diverse cross section of users
It is always important to engage a broad group of users. Requirements
gathering sessions are usually effective in involving groups of users.
The facilitator of these discussions is critical providing leading questions,
understand the business and be able to gather information effectively.
It is often difficult for participants to articulate their daily routines and
processes. The success of requirements gathering is contingent on the
ability to extract detailed and high level information and then create a
global picture of the needs of the organization.

Requirements: The first critical step
“A good beginning makes a good ending.”
(Read yourself)
 The requirements gathering process may not guarantee a successful project but
provides a foundation for project that can be managed to meet well defined
objectives.
 Requirement gathering sessions should be designed to define business
processes, owners, and reporting needs.
 Requirements sessions should set a proactive tone for the project. Many project
teams get into the mindset of being reactive is addressing issues. A clear, concise
requirements document will create the baseline to building scope, project plans,
risk mitigation plans.
 Requirements provide the stepping stone to deriving scope. There are times
where at the end of the requirements phase, scope cannot be clearly defined. It
is essential at this point that the project methodology is modified to perhaps
include a proof of concept or prototyping phase.

Requirements: The first critical step
 Our requirements sessions are designed to be interactive and not follow a script.
This environment allows users to learn from the other subject manager experts
in the sessions as well as create a baseline for strong communication.
 These sessions should include how communication will be delivered, the project
team and their roles on the project and tools that will be used to document such
as an issues log, requirements matrix, or weekly status reports.
 A clear set of defined goals and objectives, reviewed throughout the term of the
project is a essential to manage expectations and avoid project pitfalls.

In general, one of the biggest problems that globally/nationally dispersed teams face in
requirements gathering and systems analysis is communication.
Solution?

Why are we different (About WG Consulting)
1. We follow the research and study what works. Our professionals have
researched the results of project success and project failure. The WG team
utilizes world-class methodologies to deliver value-creating solutions
based on each client’s unique operating needs. Our team’s thorough
understanding of operational and regulatory risk is the key to competitive
results that mitigate such risks for our valued clients.
• Research = 4.5% world population is color blind
• 7-9 items view at a time (usability)
2. We adapt our approach to your needs. Best business practices have
their value, but these processes cannot be applied to all organizations.
 Project methodology and approach can only be determined based on an
understanding of users, business processes, resources, knowledge of the
software and the requirements of the project. (methodology)

Why are we different (about WG Consulting)
3. We have been there. Our team is comprised of professionals with at
least 15 years of industry and consulting experience. Our consultants
have been IT analysts, administrators, project managers, and IT
professionals that have broad industry experience.
• This experience provides you with an educated, agile team that can adapt
to the project methodology, culture and needs of your organization.
4. Communication. Our consultants focus on constant and effective
communication with the client in the form of documentation, weekly
meetings, demonstrations and training sessions.
• It can be done through software?

 What features could you add to the product that would better accommodate
end user needs for older people aging 65+?
– Voice command
– Many menus
– Large text
– Audio reminders
 In which software development process model would requirements and
design be two completely separate phases?
– RAD
– Spiral
– V-model
– Waterfall
Quiz

 Requirements: A restaurant manager wants to develop an
in house software. Goal is that customers can place order
directly to the kitchen and kitchen can view it. Moreover
customers can change orders and pay the bills.
 There should be kids page for games and easy for kids to
make an order themselves.
• Quiet simple case 
• Explore more development models in slide no. 11
• In slide no. 12 what does involving means?
• In slide no. 16 explore Agile Methodology
• How communication among team can be done through software?
• Slide no. 18 contact related person to ask at least one question and paste also
on question.computingcage.com (always)
Restaurant Scenario

system level requirements gathering and analysis

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to system level requirements gathering and analysis

Similar to system level requirements gathering and analysis (20)

More from university of education,Lahore

More from university of education,Lahore (20)

Recently uploaded

Recently uploaded (20)

system level requirements gathering and analysis