system level requirements gathering and analysis

www.wgconsulting.com

Requirements Gathering: The first step to project success

Lecture 1BSIT-6th

http://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&docid=REEuAtRtpTgaFM&tbnid=B0-9r068tc9AkM:&ved=0CAUQjRw&url=http://www.phaseware.com/phaseware-Successful-CXO-Committed-to-Customer-Service/bid/48396/Why-Do-Customer-Support-Initiatives-Fail-Five-Fatal-Faults&ei=cm8CU4SkB6LD2wWEuYDwCQ&psig=AFQjCNHIHdMnAmAMt9B4lQzxYhW8wSW1BQ&ust=1392754920956122





Copyright 2014, WG Consulting, LLC 305/01/2023

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

http://www.deepfriedbrainproject.com/



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 usedSpiral• Incremental build• Additional functionality added later• Prototyping usedWaterfall• 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 resourcesScrum• 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?

http://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&docid=REEuAtRtpTgaFM&tbnid=B0-9r068tc9AkM:&ved=0CAUQjRw&url=http://www.phaseware.com/phaseware-Successful-CXO-Committed-to-Customer-Service/bid/48396/Why-Do-Customer-Support-Initiatives-Fail-Five-Fatal-Faults&ei=XGYCU47YLcr22gWfi4CIDw&bvm=bv.61535280,d.aWc&psig=AFQjCNF4fom3wxEixcHPPa_PvjVlSULLUg&ust=1392752575160728



http://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&docid=fnRCcRJ1V5h46M&tbnid=dWinH7hRQRkqPM:&ved=0CAUQjRw&url=http://users.csc.calpoly.edu/~jdalbey/206/Lectures/IntegrationStrategies.html&ei=8mYCU7vNKqbC2wWEm4G4DQ&psig=AFQjCNF4fom3wxEixcHPPa_PvjVlSULLUg&ust=1392752575160728


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

Education