System Level Requirement Gathering

1
Requirements Gathering The first step to
project successLecture 1BSIT-6th
2
(No Transcript)
3
The Facts

• 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

4
What are the statistics?

• 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)

5
What is the problem?

• 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 whats in and whats
  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 stepIts
  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 produceIt cant
  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.

6
Why Projects Fail.
7
Why are requirements important?

• 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.

8
Five key components of requirements gathering

• 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.
  

9
Five key components of requirements gathering

• 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.

10
Five key components of requirements gathering
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.
11
Five key components of requirements gathering
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

12
Five key components of requirements gathering
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.
13
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.

14
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.

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

• 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

17
Restaurant Scenario

• 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?
• Post questions on question.computingcage.com
  (always)