Every design project encompasses several Tasks, their related Use Cases and the many Business Rules that define them.

We capture that info in the Business Requirements.

Things to Do

Describe “what is”. Refer to existing norms and standards when appropriate.

Things to Avoid

Avoid telling “how to”. Make no reference to specific buttons, dialog boxes or other on-screen controls.

Identify the “WHY”

Overview

The first section provides an overview of the structure of the Functional Requirements document itself, the contents of the rest of the document, how it is organized and its intended audience.

Ownership: Product Manager, Client, Market Specialist, Business Analyst

Background

This section defines the environmental conditions that have shaped the product. These may include:

  • History
  • Market Forces
  • Business Case
  • Legacy Issues
  • Competition
  • Perceived customer motivation

Purpose and Scope

This section provides a general description of the product. This may include:

  • Name of the product to be produced (version )
  • Perquisites and dependencies on previous products
  • Target audience
  • Anticipated impact

Reference Materials

This section provides references to all other publications (books, technical manuals, standard documents) that are applicable to the Functional Requirements document, including the sources from which the references may be obtained.

Scope

This section is absolutely critical to the product development process, as it provides all Project Team members with a common ground description and context for the product, the environment, the business case, the critical issues and the major players.

Ownership: Product Manager, Market Specialist, Business Analyst

  • Product Functions
  • Product Perspective
  • User Characteristics
  • User Interface
  • General Constraints and Guidelines
  • Assumptions, Dependencies and Risks

For example : Marketing

Business needs

Describe what you want to accomplish, as a business, and your criteria for success. (Edit the examples below as appropriate. Add items, as needed.)

Priority/Immediacy/Goals

Tools

Metrics for Success

Identify potential customers

“pre-qualification” form (required fields / contact info)

  • Name, Company, Phone Number

Push marketing materials

Ability to print

  • # of “print page” clicks on marketing collateral

Generate customer phone calls to sales force

On-site phone listing

  • # of phone calls to Sales Desk generated by website

Visitor self-qualification

“pre-qualification” form (optional fields / qualification info)

  • Business info, volume

Customer needs

Identify your customers and visitors, their likely agenda, and what they want to accomplish. For example: 

 

Existing customer

Profile: Break out customer by business line or market size?

Goal: Speedy access to Mortgage service

Priority: Quick sign-on for existing customers

Business Opportunity: Login to legacy site

Self-directed visitor

Profile: Describe their agenda?

Goal: Does businessoffer viable solutions to my needs?

Priority: Directed Search for info

Priority: Sign up

Business Opportunity: I need to talk to a sales rep

Casual visitor

Profile: Why did they come?

Goal: Learn about our Mortgage services

Info retrieval

Priority: Print out materials

Business Opportunity: Call Me

Considerations

Brand Strategy & Positioning

  • What is your overall strategic objective? Does the Brand reflect that?
  • Do customers recognize the service brand more than the company brand?

Customers

  • What are typical customer relationship development stages?
  • What is our value proposition?

Marketing Synergy

  • Are there partnerships/cross-selling?
  • Describe offline Marketing initiatives. Can they be integrated with online?

Critical success factors

Rank the importance of these marketing objectives.

Objectives

  • Catch up with the competitors’ online presence
  • Gain new clients by targeting specific NEW segments of client population
  • Generate more inquiry phone calls to Sales Desk due to the information/data on the website
  • Get more qualified leads/customer contacts
  • Understand customer needs
  • Distribute marketing materials
  • Provide information about specific products
  • Focus visitor attention on competitive advantage(s)
  • Focus visitor attention on particular service(s)

 

Functional Requirements Content

This section contains a description of the detailed requirements that will directly affect the design of the software being developed, depending on the type and complexity of the system being developed.

Processing Requirements

Ownership: Development Manager, Technical Architect, Client

  • Inputs
  • Processing
  • Outputs

Performance Requirements

Ownership: Technical Architect

Design Constraints & Benchmarks

Standards Compliance

Ownership: Interface Architect, Technical Architect, Business Analyst

  • Report Formats
  • Naming Conventions
  • Accounting Procedures and Audit Tracing

Hardware And Software Limitations

Ownership: Technical Architect

Technical Interface Requirements

Ownership: Technical Architect

Human Interface Requirements

Ownership: Interface Architect, Business Analyst

Security

Ownership: Technical Architect

Development

Ownership: Interface Architect, Technical Architect

Product Support & Maintenance

Document Checklist

  • When all is said and done, we still need a reality check…
  • Does the document conform with the Guidelines?
  • Is there an understanding of the problem to be solved?
  • Are the requirements complete?
  • Are all functional requirements completely defined?
  • Are the requirements correct?
  • Are the requirements consistent?
  • Are all requirements clear and unambiguous?
  • Are the requirements feasible?
  • Are there adequate verification and acceptance criteria?
  • Are there sufficient quality requirements?

 

The UX Practitioner is “a Business Analyst with Design Skills”

 

© The Communication Studio LLC

Advertisements