Seminar 10P - Project Leadership and Requirements Gathering: It Doesn't Need to Be a Root Canal...

8/11/2019 Seminar 10P - Project Leadership and Requirements Gathering: It Doesn't Need to Be a Root Canal (separate regi…

http://slidepdf.com/reader/full/seminar-10p-project-leadership-and-requirements-gathering-it-doesnt 1/28



There are many articles, surveys, and reports on the common theme “Why do projects fail.” It’s probably no surprise that poor or incomplete requirements is among the list leaders. A meta survey analysis of project failure surveys done in the late 90s showed incomplete requirements at the top of the list (based on the 1994 Standish Report and cited in the 2003 article from Frese http://www.umsl.edu/~sauterv/analysis/6840_f03_papers/frese/ ):

The top 5 indicators found in “Challenged” projects are:1. Lack of User Input2. Incomplete Requirements & Specifications3. Changing Requirements & Specifications4. Lack of Executive Support5. Technical IncompetenceThe top factors found in “Failed” projects1. Incomplete Requirements2. Lack of user involvement3. Lack of Resources4. Unrealistic Expectations5. Lace of Executive Support6. Changing Requirements & Specifications7. Lack of Planning8. Didn’t Need it Any Longer9. Lack of IT management10. Technical Illiteracy

(c) University of Wisconsin Gathering Business Requirements Section 1 page 11

Project Leadership and Requirements Gathering: Educause 2014 Annual Conference page 15



The Different Types of Business Requirements:

What is a requirement?A requirement is a condition of capability a stakeholder needs to solve a problem or achieve an objective.

The IIBA’s 4 levels of Business RequirementsThe International Institute for Business Analysis (IIBA) categorizes requirements into: 1. Business requirements2. Stakeholder/user requirements3. Solution requirements4. Transition requirements.

Business Requirements:These are the needs, objectives and goals of the organization, that describe the reason for

the project and how it will be measured. They are usually obtained from project sponsor, manager of users and other senior stakeholders that would be affected by the project result. Business requirements are captured first and provide the framework from which requirements are gathered. Examples include:In a customer relationship management (CRM) project:• “we expect the CRM solution to enable us to better target our promotions to our

customers”• “we want to be able to assess how each customer contributes to our bottom line”• “we desire that all our customer transactions can be migrated into the new solution”

Stakeholder/User Requirements:These define the needs of a particular user or groups of users, and how these users will interact with the system. They act as the link between the business objectives and the solution requirements. They are collected from users that will perform their tasks in the new system. They are collected throughout the requirements gathering process in an iterative fashion. Examples include:In an enterprise resource planning (ERP) system project:• “the solution should be able to process staff timesheets”• “the solution should be able to capture accounting documents, process tax on

customer’s orders, and generate end ‐of ‐period financial statements”• “the solution should provide information on the status of each customer order”

Solution Requirements:These outlines what the solution will do in line with business and stakeholder requirements. They provide more detailed information and guide the design of the solution. They are typically collected from technical resources including Infrastructure, Data and Network Analysts; Subject Matter Experts; Suppliers and Contractors; and other external sources required for data migration.





Solution Requirements (continued)Solution requirements can be further grouped into functional and non ‐functional.Functional Requirements: are functions that the solution should perform. It will include a set of inputs, activities to be performed to these inputs (referred to as the behavior), and the

outputs. Examples

include:• “The solution should be able to take orders from customers and generate an invoice to the

• customer”;• “The solution should be able to process payroll bi‐weekly and provide pay ‐stub to every

employee”.

Non ‐Functional Requirements: are those things needed for the product to work the way it is designed to. They specify criteria to be used to judge the operation of a solution, rather than the specific behaviors. They are usually technical and quality parameters such as performance, security, regulatory rules, capacity, etc.• “The solution should allow access from 2000 concurrent users”• “The solution should be able to process one million transactions daily”• “The solution should prevent access from un ‐authorized users”• “The solution should limit every user’s pin to four characters”

Transition Requirements:These are temporary capabilities that the solution should have in place to facilitate a smooth transition from the current state. It will include all such things needed to run the new solution such as data conversion, skills gaps, archiving and storage requirements, etc. Examples include:• “How much data will be converted? 1 yr, up to last year ‐end??”• “What do users need to be trained on before going live“• “What documentations should be in place before going live”





Another popular view: Weiger’s Three Level Model

Business requirements are statements of the business rationale for authorizing a project. They include a vision for the product/software that is driven by business goals, objectives, and strategy. Business requirements describe high level purpose and needs that the product will satisfy to increase service and/or revenue, decrease operating expense, or meet regulatory obligations. The vision provides a long term view of what the end product will accomplish for its users and should include a statement of scope to clarify what capabilities will and won’t be provided. Business requirements can include high level features of the system. Examples include:

“provide payments to vendors”“enable managers to estimate and schedule jobs”“provide accurate estimates to external donors”

Typically business requirements are included in the project charter

User Requirements describe the tasks that user’s need to accomplish the work required and meet the necessary quality characteristics of the task.. Users can be human or other systems/software/hardware.While users are the primary audience for user requirements, technical staff often benefit the most from understanding these critical needs. User requirements are the bridge between business goals and the detailed product/software requirements that engineers/developers use.

Software Requirements are the details descriptions and specifications of all the functional and non functional requirements for the system It’s important to capture all the various levels of customer requirements and to remember that different stakeholders will have different perspectives and insight





Yet another Model: The 7 Category Requirements ModelAnother common model for requirements is the 7 category model. The categories are:

1. Customer2. Functional3. Non ‐functional

4. Performance5. Design6. Derived7. Allocated

Customer Requirements:Statements of fact and assumptions that define the expectations of the solution in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of solutions engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing:

1. Operational distribution or deployment: Where will the solution be used?2. Mission profile or scenario: How will the solution accomplish its mission

objective?3. Performance and related parameters: What are the critical solution parameters

to accomplish the mission?4. Utilization environments: How are the various solution components to be used?5. Effectiveness requirements: How effective or efficient must the solution be in

performing its6. mission?

7. Operational life

cycle:

How

long

will

the

solution

be

in

use

by

the

user?8. Environment: What environments will the solution be expected to operate in an

effective manner?

Functional Requirements:Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the top ‐level functions for functional analysis.

Non ‐functional Requirements:Non ‐functional requirements are requirements that specify criteria that can be used to

judge the operation of a solution, rather than specific behaviors.





The 7 Category Requirements Model (continued)

Performance Requirements:The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on solution life cycle factors; and characterized in terms of the degree of certainty in their estimate, thedegree of criticality to solution success, and their relationship to other requirements.

Design Requirements:The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.

Derived Requirements:Requirements that are implied or transformed from higher ‐level requirement. For example,

a requirement for long range or high speed may result in a design requirement for low weight.

Allocated Requirements:A requirement that is established by dividing or otherwise allocating a high ‐level requirement into multiple lower ‐level requirements. Example: A 100 ‐pound item that consists of two sub solutions might result in weight requirements of 70 pounds and 30 pounds for the two lower ‐level items.





Elements of a good Requirements Statement

What is a requirement?A requirement is a condition of capability a stakeholder needs to solve a problem or achieve an objective. Requirements may contain one or more elements as depicted below:”

Characteristics of a Good Requirement (adapted from the IIBA BABOK v2.0 )Requirements have one or more elements, and can be categorized in many ways. What makes a well documented requirement? There are 9 areas that we look to when

determining whether

it’s

a “good”

requirement

statement:1. Unambiguous: the requirement should be clear and understandable

2. Complete: the requirement should be self ‐contained and non ‐repetitivedescribe it.

3. Feasible: the requirement can be accomplished within the project constraints4. Consistent: the requirement is compatible with other requirements5. Testable: the requirement can be shown in the solution6. Cohesive: the requirement describes only one need7. Modifiable: the requirement can be changed without dramatic impact on other

reqs.8. Correct: the requirement should be free of defects or rework

9. Verifiable: the requirement maps to the customer’s job’s/outcomes/objectives

Image: I. Alexander and L. Beus ‐Dukic, Discovering Requirements: How to Specify Products and Services, Wiley, 2009





Unambiguous: the requirement should be clear and understandable. Ask Yourself:

• Do you understand what it means?• Can an outside reader tell you what it means?• Are all acronyms and business terms defined?• When you use plain terms there isn’t any room for misunderstanding.

Example:A sentence reads:

“The system response time from when the administrator clicks on the enter button must be the same as all other systems”

Using the term “equal to” the sentence reads:“The system response time, from when the administrator clicks the enter button, should be equal to all other systems”

This ensures a short clear requirement that is not open to interpretation. Also, use words correctly and avoid euphemisms. Take the following statement:

“The system will provide substantial expense decrease due to the ubiquitous implementation of pre ‐owned hardware”

Not only does it use fancy wording, it doesn’t get to the point. Instead the following is clearer:

“When used hardware is installed, staff costs will be reduced”

Complete: the entire set of requirements that you produce should represent all relevant requirements. Each individual requirement should be self ‐contained, non ‐repetitive and include everything needed to describe it. Ask Yourself:

• Do these requirements represent the entire picture?• Is there any repetitive information within individual requirements?•

Are there any repeating requirements that say the same things?• Complete requirements will allow the development team to start their work withlittle clarification.

Feasible: can the requirement be implemented in the current technical infrastructure, within the project budget, timelines and using the assigned resources. Ask Yourself:

• Is this requirement actually possible to implement?• Can the entire requirement package be implemented within the assigned projecttimelines?

Consistent: the requirement should be coherent and uniform and compatible with other requirements. Ask Yourself:

• Does one requirement conflict with another?• Does it use the same terms throughout? (e.g. client vs. customer)• When you are consistent you increase the accuracy of the resulting solution andagain there are no misinterpretations of “who, what, how, or when.”





Testable: there should be an ability to test that a requirement was included in the solution. Ask Yourself:

• Is it possible to design a test to ensure the requirement was included in the solution?• What signifies pass or fail?

Cohesive: the requirement should specify only one need. Ask Yourself:

• Is there more than one “need” stated in this requirement?• Does the requirement touch on a number of things?

When your requirements are cohesive they will be easier to trace and track.

Modifiable: the requirement should be able to be changed without a great impact on the other requirements. Ask Yourself:

• Are any requirements repeated?• Are there requirements intermixed with other requirements? (e.g. the system shallreside on a• Microsoft Windows platform and be accessible to staff who have vision challenges)

Each requirement should only appear once in the requirements document. Consider cross ‐referencing subsequent instances back to the original requirement rather than creating another one. A table of contents or matrix will help you to do this.

Correct: the requirements should be understandable, clear and free of defects. Ask Yourself:

• If someone without knowledge of the product read the requirements would theyunderstand what was being asked?•

Has the

sponsor

and

SMEs

agreed

that

they

are

accurate?• Requirements that are correct will lead to fewer changes required and defects

identified during testing.

Verifiable: did the client get what they asked for. Ask Yourself:

• Do the requirements meet the original business objective?• Were the requirements inspected by the project team?• Are the requirements complete, consistent and feasible? If not they cannot be verified.• Can the requirements be tested for defects?

You can determine if your requirements are complete by including the client and the project

team in a team review. CMMI calls this activity a “Peer Review.” The reviews are incremental and serve to identify defects. They are extremely useful in identifying ambiguous, unverifiable requirements that are not clear enough to begin the design process and help to reduce rework.





Let’s assume that it’s been decided that requirements are needed. What’s the preferred approach? Opinions vary. One of the most widely documented requirements gathering methodologies is for software based solutions and is displayed above and detailed below:

Elicit: Identify stakeholders, documentation, and external sources of requirements

information and solicit requirements from those sources

Analyze: Explore how users interact with the system, and develop models that communicate those interactions to various audiences. Verify requirements to identify inconsistencies, ambiguities, omissions and errors. Prioritize the requirements by removing unnecessary ones and ranking the rest to help with implementation/development decisions.

Specify: Differentiate and document functional and non functional requirements, identify quality attributes and constraints, and check that requirements are documented completely and in a testable way

Validate: Examine the requirements to insure they satisfy customer needs through testable observations





A modification of this approach, made popular by the Wisconsin ‐based consulting firm, RequirementsQuest.com is the following methodology:

ElicitationE1 Identify stakeholdersE2 Identify requirements sources

E3 Elicit requirementsAnalysis

A1 Document assumptionsA2 Identify conflicts and dependenciesA3 Identify constraints and risksA4 Prioritize requirements

RepresentationR1 Create graphical models and prototypesR2 Create textual documents

ValidationV1 Identify characteristics of qualityV2 Eliminate ambiguitiesV3 Trace requirementsV4 Conduct requirements reviews

Change ControlC1 Baseline accepted requirementsC2 Follow change control processC3 Maintain requirements

Other product development focused scholars (Ulwick and Bentencourt) suggest a similar but different approach focused on new product development:

1. Plan outcome based customer interviews2. Capture desired outcomes3. Organize outcomes4. Rate outcomes for importance and satisfaction5. Use outcomes for product implementation/development

Finally, at the UW’s Business Analysis Certificate series, http://exed.wisc.edu/ba this model is used:

Plan Elicit and

Analyze Document

Verify and Quantify

Manage Change





Project Leadership and Gathering Business Requirements: The Summary Sheet

Course web site – http://go.wisc.edu/3j69fd

Plan

Elicit and Analyze

Quantify and Verify

Manage Change

Document and

Specify

Activities Identify proj. Champion Draft charter including scope, risks,

constraints, business case, goal(s) andsuccess criteria

Review past project work Select proj mgmt. methods and tools Understand current state Identify project team and determine

roles responsibilities

Identify stakeholders throughnomination, doc review, and genericmodels

Prioritize stakeholders Plan communication strategy

Develop interview questions Develop collection and sorting

techniques Sort and categorize interview output

Develop written descriptions of interviewrequirement results (traditional, job/outcome based, story based)

Develop visual descriptions of interviewresults

Add any re quirements not identified ininterviews

Correlate/score requirements tostakeholder groups Determine technicalspecifications and non ‐functionalrequirements needed to support

prioritized results Correlate/score technical specifications

to most important requirements Communicate to stakeholders findings

Iterative feedback with stakeholders Refine communication plan Refine change management plan Develop bu y‐in strategies

Tools/References (Examples on rear) Project Charter SMART and stretch goals Project visioning Document review (p64)

Pitfall identification/avoidance (p7 ‐12) Project mgmt. methodologies (p27 ‐34) Team building Process Map (p41 ‐52) Direct observation (p44) Data flow diagram (p53 ‐55) RACI chart (p70 ‐72)

Stakeholder models (p64 ‐65) Stakeholder analysis and prioritization (p68 ‐69) Kotter organizational change models (p142 ‐143) Pyramid approach to questions (p75) Stepladder interview and Value maps (p76 ‐77) # of interviews compared to % total reqs. (p78) Affinity diagramming (p79) Generic requirements questions (p80 ‐89) Job and outcome mapping (p8 ‐9)

Personas and Scenarios (web site reading) Use cases and User stories Decomposition diagrams (p56 ‐57) Data flow diagrams (p53 ‐55) Process maps (pp. 41 ‐52)

Decision scoring matrices (p102 ‐104) Kano model analysis (p100 ‐101) QFD and HOQ (p105 ‐113) Surveys for additional data (p114 ‐137) SME interviews and feedback (p75 ‐77)

Prototype or storyboard results

Crucial conversations (p90 ‐98) Stakeholder analysis and mapping (p62,66) Kotter change model (p142 ‐143) Buy‐in categ ories (p144 ‐151)




Project Leadership and Gathering Business Requirements: The Summary Sheet

QFD House of Quality (p107)

Examples:

urse web site – http://go.wisc.edu/3j69fd

Decomposition Diagram(p56)

RACI Chart (p70)

Why, How,

What

Who, When, Where Which, Yes/No Questions

Question Pyramid (p75)

Data Flow Diagram (p54)

SIPOC Diagram (p59)

rucial Conversations (p94)

Affinity Diagram (p79)




Completion of today’s seminar qualifiesyou for an official EDUCAUSE badge:

After the seminar and before Oct. 21 :

Visit credly.com/claim

Enter code2014-EDUCAUSE-10P

Follow the prompts toprovide a reflection on how you will applyknowledge from this seminar

After you submityour reflection:

EDUCAUSE staff will reviewyour submission

Look for an email whenit has been approved

Then share your badge onprofessional and socialnetworks or your own site,blog or résumé


Seminar 10P - Project Leadership and Requirements Gathering: It Doesn't Need to Be a Root Canal...

Documents

Transcript of Seminar 10P - Project Leadership and Requirements Gathering: It Doesn't Need to Be a Root Canal...