Requirements and Drupal: Planning for Successful Projects

September 13, 2012Requirements & Drupal: Planning for Successful Projects

R.J. Townsend, Manager, Drupal Solutions - NavigationArtsJon Riekse, Director of Business Analysis - NavigationArts

• NavigationArts is unique in the web space. We combine best practices in User Experience Design and Technology Consulting, excelling where these practices overlap.

NavigationArts: Market Position

• Comprehensive user-centered design methodology that aligns business goals

Design and Technology Consulting, excelling where these practices overlap.

with user needs, creating user experiences that drive enterprise value

• Best-in-class technology and software development skills that deliver the user experience through rich front-end development, configuration of complex interaction functionality and integrationinteraction functionality, and integration of enterprise applications and data

(703) 584 – 8949 www.navigationarts.com @navigationarts2

Agenda

• Requirements Overview

Agenda

• Requirement Types & Samples

• Translating Requirements to Specification / DevelopmentTranslating Requirements to Specification / Development

• Requirement Activities

• Drupal Requirements

• The Business Analyst & Drupal

• Functional Re-use

• Requirements & Contributing back to the Open Source Community

(703) 584 – 8949 www.navigationarts.com @navigationarts

g y

3

Requirements: What are they good for?

Sorting through the baggage

Requirements: What are they good for?

• Requirements != Bureaucracy when done intelligently

• Describing something complex should be easier/faster/cheaper thanDescribing something complex should be easier/faster/cheaper than actually building it – when using the appropriate level of abstraction

• It’s about the right people giving the right input at the right timeg p p g g g p g

• Promoting mutual understanding

75% i ti 25% d t ti h ld b th d t f• 75% communication, 25% documentation – should be the product of communication, not the means of communication

• Keep the docs interesting meaningful digestible and productive – a


• Keep the docs interesting, meaningful, digestible, and productive – a means to explain and educate

4

Requirements: The Case Against

• We don’t have the time or budget to document requirements

Requirements: The Case Against

• Seems like too much paperwork, let’s build something already!

• Our project is too small to necessitate requirementsOur project is too small to necessitate requirements

• Our project is too large to necessitate requirements (we will never know everything until we start developing)y g p g)

• We use agile

W lik t h i d• We like to change our minds


Requirements: The Case For

• Taking planning seriously, adding some formality, mitigating risk – meeting

Requirements: The Case For

the formality of your clients/stakeholders

• Doesn’t assume we are all talking about the same thing or speaking the l l t il ( d t j t l tt d i b )same language, leaves a paper trail (and not just a cluttered inbox)

• Describing and agreeing to the end state before it’s done (for clients or your internal business teams) documenting scope for budget/resourcesinternal business teams), documenting scope for budget/resources

• Agreement to the outcome - how do we know when we’re done?

• Managing change - being on the same page as your project sponsors/clients


Requirements Overview

• A requirement is a description of what the website will do.

Requirements Overview

• A requirement can consist of a text description or a visual representation (annotated wireframe, design, model, diagram) – whatever it takes to get th i tthe point across.

• A requirements document is a collection of consistent requirements – can describe the same thing a few different ways to ensure understandingdescribe the same thing a few different ways to ensure understanding

• The goal of requirements is to describe as precisely as possible what is to be built, giving more attention to the most complex aspects, where thebe built, giving more attention to the most complex aspects, where the highest level or risk can occur (using your time wisely)

• Defines the boundaries of the website/system. Helps avoid scope creep.


y

7

Sample Model: Integration Diagramp g g



Warning: Abstraction Ahead

• Talking abstract concepts about an abstract

Warning: Abstraction Ahead

system – using language

• A picture is worth…a lot

• Know your audience, and your risks

• Avoid documenting the documentation – when you have g ydocumentation to reference other documentation you are starting down a slippery slope

• Use common sense, trust your intuition over the ‘correct’ way to document requirements


• Keep it grounded, at the end of the day if it doesn’t make the product better it wasn’t worth it. Quality Assurance starts with this work.

10

Types of RequirementsTypes of Requirements


Business Requirements

• Aligning the business goals to the project

Business Requirements

• Very useful for prioritizing functionality and defining phased approaches

• ‘How do you envision success for the project and how is it measured?’How do you envision success for the project and how is it measured?

• Drupal: The value of Open Source Technology

• Drupal: Leveraging all available modules/code

• Higher Ed examples: More applicants, updating the brand, more ffi i / i i t SEO b d d i i d l l fefficiency/easier maintenance, SEO based redesign, increased level of

satisfaction of prospects through the enrollment process. Measure with # of qualified applicants, rejection rates, analytics (# of unique visitors, time


on site, decreased bounce rates), run a recurring survey.

User Requirements

• The User Experience (UX) – aligned to the business goals of your

User Requirements

organization

• Think from the outside in, empathize with your website visitor’s point of iview

• Defining your audience segments, their needs/concerns, what tasks do they need to completethey need to complete

• ‘What relationship does your organization have with your visitor segments (donors, members, investors, consumers, partners)?’(donors, members, investors, consumers, partners)?

• Informing your Information Architecture / Sitemap / Taxonomy


• Going from the analog to the digital, eventually into roles & permissions

Higher Ed User Segmentation ExampleHigher Ed User Segmentation Example

• Prospective Student – Undergraduate (18 22)

• Alumni

D(18-22)• Transfer Student – Undergraduate (18-

22)

• Donor

• Parents of Prospective Student (18-22)

• Prospective Student –Undergraduate (22+) (9 credit)

Prospective Student Graduate Full

( )

• Current Faculty

• Prospective Faculty• Prospective Student – Graduate – Full Time

• Prospective Student – Graduate – Part Time

• Prospective Faculty

• General Public

• Prospective Student - Non-Accredited Adult Learner

• Current Student

• Industry Executives/Corporations


• Prospective Student - OnlineExecutives/Corporations

• International Students

Use Cases Sample: Add SharePoint ServiceUse Cases Sample: Add SharePoint ServiceGoal Name Add SharePoint Service to User

Level (Business or System) Business

Primary Actor(s) Customer Administrator

Trigger Customer Administrator wants to add the SharePoint service to an existing user.

Pre-conditions • Customer Administrator has purchased SharePoint.• Customer Administrator is logged in to the System and has an

active session.• At least one non resource type mailbox has been created in• At least one non-resource type mailbox has been created in

the System.

Pre-conditions Use Case # 18. Authentication

Post-conditions SharePoint service added to user.

Normal Case Steps 1. Customer Administrator navigates to the 'Users’ area of the portal.

2. Customer Administrator selects a link to ‘View All Users’.3. Customer Administrator selects the End User they want to


3 Custo e d st ato se ects t e d Use t ey a t toadd the SharePoint service to.

…

Functional Requirement Sample High LevelFunctional Requirement Sample – High Level


Functional Requirement LegendsFunctional Requirement Legends


Functional Requirement Sample Detail LevelFunctional Requirement Sample – Detail Level


SJU Functional Annotation ExampleSJU Functional Annotation Example


Tech / Non Functional Requirements (NFRs)Tech / Non Functional Requirements (NFRs)• Be afraid, be very afraid

• Performance requirements – baselines, internet connection speeds, geographies

A il bilit i t• Availability requirements

• Security requirements – keeping Drupal patched! SQL injections, cross site scripting hosting infrastructure security vulnerability assessmentssite scripting, hosting infrastructure security, vulnerability assessments

• Capacity requirements

• Analytics

• Compliance


• A bucket for anything you want other technical stakeholders to review

Device/Browser Support• Mobile and tablet requirements are causing a paradigm shift in how we

think and plan for website projects Prototyping with a framework like

Device/Browser Support

think and plan for website projects. Prototyping with a framework like Drupal is critical.

• It is almost always in the client’s interest to receive modern, maintainable y ,code that is not ‘hacked’ for older browsers. But verify this is the case (for example an internal site where users have to use IE7)

• Step 1: review current analytics, figure out what the %’s are, look at mobile/tablets, factor into initial planning

The website shall support the following browsers, rendering full functionality and visual aspects:• IE 8.0, 9.0• Firefox 3.x, 4.x, 5.x• Chrome’s Latest Stable Version


• Safari 5.x, iOS 3.x, iOS 4.x• Webkit Android 2.x

Progressive Enhancement / Responsive Design

• The employed CSS3 techniques shall be employed as progressive

Progressive Enhancement / Responsive Design

enhancement, providing the richest experience to modern browsers, while still making an effort to accommodate older, less capable browsers.

T k h t f b it i IE7 h d h d• Take screenshots of your websites in IE7 – show no drop shadows, no rounded corners and give your clients a piece of mind ‘that it won’t be that bad’.

• Responsive Design

• Leverage any docs onLeverage any docs ondrupal.org


Aligning Requirements to Drupal FunctionalityAligning Requirements to Drupal Functionality

• Communicating to the client the benefits of open source

• Code available

• Re-using code is going to reduce time/budget to implement

• Finding the right module (80-20 rule)

• But customizing when needed


g

• Contributing back to the community

Translating Requirements to Specification / Dev

• Requires a thorough understanding of the client, documentation (SOW,


wireframes, functional req’s, etc), and how Drupal works

• CMS spec maps out requirements to modules / technical components

• Most, if not all, of your spec document / dev plan should be determined by the time requirements are approved

• Your spec document should provide framework for how the site will be built

• CMS Spec compliments photoshop design files and requirements document



• Our CMS spec documents usually include the following:


List of all content types, fields, views, contexts, panels, blocks, theme, etc., naming conventions for each, and required config settings (pathauto, etc)

Deployment architecture

Required modules (core, contrib, custom, features) and high-level configsettings for each

Naming conventions

Our CMS spec is used in conjunction with PSD files and requirements


Our CMS spec is used in conjunction with PSD files and requirements docs; it does not live by itself.

NMWA Example CMS SpecNMWA Example CMS Spec


Requirement Activities

Gathering Requirements

Requirement Activities

• Talking to the right people at the right time

• Analyzing the right artifacts / analyticsAnalyzing the right artifacts / analytics

• Ask the same question different ways to ensure understanding especially with non-technical audiences. p y

• Prioritizing requirements and resolving contradictions

Ri d t• Rinse and repeat

Documenting Requirements – writing it down


Managing Requirements – updating and change control

Elicitation: Moving the conversation forward

• Do not avoid ‘how’ when appropriate. There are many levels of what ->

Elicitation: Moving the conversation forward

how -> what -> how.

• Do not try to stay at the same level of abstraction. If workflow cannot be d fi d l b t 3rd t API i t ti i fi d d tdefined early, but a 3rd party API integration is confirmed, document as much detail as possible, as early as possible.

• Work forwards and backwards what do we need to know to build the• Work forwards and backwards, what do we need to know to build the website

• Use your brain and experience to realize if you are making too early anUse your brain and experience to realize if you are making too early an implementation assumption, but don’t let it scare you from moving the conversation forward.


Drupal Specific Requirements Workflow SimpleDrupal Specific Requirements – Workflow Simple

• Define more granular permissions. For example, if there are authors who can only change certain sections of the website


• Define email copy

Workflow AdvancedWorkflow Advanced


Structured vs Unstructured Content

• Has significant implications to the maintenance of the website

Structured vs. Unstructured Content

• Need to know your content managers: do they know HTML, CSS, how technical savvy are they?

• Avoid misunderstanding on how the CMS backend will work

• Structured data can take more effort, but can ease the maintenance burden ,and offer more front end interactivity.

• Rules for structured data: what fields are included, sort orders for list, min/max # of elements, descriptions of empty results, and controls for paging or filtering larger sets of data


• Unstructured is harder to maintain, but can offer some flexibility without making coding/config changes.

WYSIWYG vs Plain Text

• Corresponds to structured / unstructured data

WYSIWYG vs. Plain Text

• Is really the crux of the User Experience of the back end


CKEditor Customization

• Re-use when possible, even for training documentation

CKEditor Customization


Taxonomy

• Often based off of our Information Architecture work

Taxonomy

• Use requirements for internal teams and stakeholders to start thinking in Drupal, establishing a common vocabulary

• Use a Spreadsheet:

• Vocabulary Namey

• Vocabulary Description

T P i T• Taxonomy Primary Terms

• Taxonomy Secondary Terms


• Content Types applied to

Block Configuration & Reusability

• Identify re-usable blocks in initial visuals (low fidelity wireframes).

Block Configuration & Reusability

• Need to think about modularity early


D6 to D7 Migrations

• Functional Analysis: what has to stay, what has to be added, what is

D6 to D7 Migrations

deprecated.

• Content type inventory

• Custom module inventory

• Functional to D7 module mappingpp g

• Content migration strategy


The Business Analyst & Drupal

• Strategic: creatively figure out how to help projects succeed. Strategy and

The Business Analyst & Drupal

ideation is fun – but this has to be grounded in technical reality

• Helps to have a development background (and to know Drupal, even from t d i t)a power user standpoint)

• Helps to be an extrovert, likes to communicate and explain technical concepts to non technical peopleconcepts to non-technical people

• Has to be flexible!!

• Runs logic/system interference with the business stakeholders for the development lead and resources


• Is often a system thinking vs. purely visual thinkers – likes to think about patterns

Functional Reuse for Client Services

• The BA and Drupal Lead should know what the development teams are

Functional Reuse for Client Services

working on

• They should connect the dots between various projects

• Help put reusable functionality in front of other clients

• Be familiar with the technical LOE

• Always talk with the developers post-mortem, what worked, what took too much time, what was abstracted for reuse

• Don’t reinvent the wheel

• Establish a functional library in your organization if you are dealing with


• Establish a functional library in your organization if you are dealing with multiple projects, establish process for updating

Contributing Back

• Requirements & Contributing back to the Open Source Community

Contributing Back

• Visual examples

• The community can contribute with documentation and examples not justThe community can contribute with documentation and examples, not just code.

• Requirements section on Drupal.org?q p g


Q & A

• Open Floor

Q & A

Connect with NavArtsCall: (703) 584 – 8949Call: (703) 584 – 8949Tweet: @navigationartsEmail: [email protected]: www navigationarts comVisit: www.navigationarts.com
