0
Requirements & Drupal: Planning for Successful Projects      September 13, 2012R.J. Townsend, Manager, Drupal Solutions - ...
NavigationArts: Market Position•       NavigationArts is unique in the web space. We combine best practices in User Experi...
Agenda• Requirements Overview• Requirement Types & Samples• Translating Requirements to Specification / Development• Requi...
Requirements: What are they good for?Sorting through the baggage• Requirements != Bureaucracy when done intelligently• Des...
Requirements: The Case Against• We don’t have the time or budget to document requirements• Seems like too much paperwork, ...
Requirements: The Case For• Taking planning seriously, adding some formality, mitigating risk – meeting  the formality of ...
Requirements Overview• A requirement is a description of what the website will do.• A requirement can consist of a text de...
Sample Model: Integration Diagram   p              g          g8     (703) 584 – 8949   www.navigationarts.com   @navigati...
9   (703) 584 – 8949   www.navigationarts.com   @navigationarts
Warning: Abstraction Ahead•    Talking abstract concepts about an abstract     system – using language•    A picture is wo...
Types of Requirements11    (703) 584 – 8949   www.navigationarts.com   @navigationarts
Business Requirements• Aligning the business goals to the project• Very useful for prioritizing functionality and defining...
User Requirements• The User Experience (UX) – aligned to the business goals of your  organization• Think from the outside ...
Higher Ed User Segmentation Example                                                      • Alumni • Prospective Student – ...
Use Cases Sample: Add SharePoint Service     Goal Name                      Add SharePoint Service to User     Level (Busi...
Functional Requirement Sample – High Level16    (703) 584 – 8949   www.navigationarts.com   @navigationarts
Functional Requirement Legends17    (703) 584 – 8949   www.navigationarts.com   @navigationarts
Functional Requirement Sample – Detail Level18    (703) 584 – 8949   www.navigationarts.com   @navigationarts
SJU Functional Annotation Example19    (703) 584 – 8949   www.navigationarts.com   @navigationarts
Tech / Non Functional Requirements (NFRs) • Be afraid, be very afraid • Performance requirements – baselines, internet con...
Device/Browser Support• Mobile and tablet requirements are causing a paradigm shift in how we  think and plan for website ...
Progressive Enhancement / Responsive Design• The employed CSS3 techniques shall be employed as progressive  enhancement, p...
Aligning Requirements to Drupal Functionality• Communicating to the client the benefits of open source• Code available• Re...
Translating Requirements to Specification / Dev• Requires a thorough understanding of the client, documentation (SOW,  wir...
Translating Requirements to Specification / Dev• Our CMS spec documents usually include the following:     List of all con...
NMWA Example CMS Spec26   (703) 584 – 8949   www.navigationarts.com   @navigationarts
Requirement ActivitiesGathering Requirements•      Talking to the right people at the right time•      Analyzing the right...
Elicitation: Moving the conversation forward• Do not avoid ‘how’ when appropriate. There are many levels of what ->  how -...
Drupal Specific Requirements – Workflow Simple     • Define more granular permissions. For example, if there are authors w...
Workflow Advanced30    (703) 584 – 8949   www.navigationarts.com   @navigationarts
Structured vs. Unstructured Content           vs• Has significant implications to the maintenance of the website• Need to ...
WYSIWYG vs. Plain Text        vs• Corresponds to structured / unstructured data• Is really the crux of the User Experience...
CKEditor Customization• Re-use when possible, even for training documentation33        (703) 584 – 8949   www.navigationar...
Taxonomy• Often based off of our Information Architecture work• Use requirements for internal teams and stakeholders to st...
Block Configuration & Reusability• Identify re-usable blocks in initial visuals (low fidelity wireframes).• Need to think ...
D6 to D7 Migrations• Functional Analysis: what has to stay, what has to be added, what is  deprecated.• Content type inven...
The Business Analyst & Drupal• Strategic: creatively figure out how to help projects succeed. Strategy and  ideation is fu...
Functional Reuse for Client Services• The BA and Drupal Lead should know what the development teams are  working on• They ...
Contributing Back• Requirements & Contributing back to the Open Source Community• Visual examples• The community can contr...
Q&A• Open FloorConnect with NavArtsCall:    (703) 584 – 8949Tweet:   @navigationartsEmail:   sales@navigationarts.comVisit...
Upcoming SlideShare
Loading in...5
×

Requirements and Drupal: Planning for Successful Projects

546

Published on

When embarking on a development project of any scale, communication and documented requirements are vital to success. The goal of requirements documentation is to clearly communicate what will be delivered and to ensure there is mutual consensus around in-scope functionality, and how the system will look and behave.

In this on demand webinar presented with Acquia, we explore best practices in project communication and associated requirements to support successful Drupal projects.

Intended Audience
This is not a technical presentation, but it does cross the boundary between technical and business owners. It is intended for the following audience groups:

Project Managers
Small business owners
Developers
Technical decision makers interested in Drupal
Web Managers

Topics Covered

R.J. Townsend, the NavigationArts Drupal Practice Lead presents along with Jon Riekse, the NavigationArts Director of Business Analysis. The two discuss:

Lessons learned from past Drupal projects
How a Business Analyst role can complement a project team
How to think about functionality and requirement reuse when applicable
How can requirements help the business (non-technical) community understand how Drupal can help their organization succeed?

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
546
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Requirements and Drupal: Planning for Successful Projects"

  1. 1. Requirements & Drupal: Planning for Successful Projects September 13, 2012R.J. Townsend, Manager, Drupal Solutions - NavigationArtsJon Riekse, Director of Business Analysis - NavigationArts
  2. 2. NavigationArts: Market Position• NavigationArts is unique in the web space. We combine best practices in User Experience Design and Technology Consulting, excelling where these practices overlap. • Comprehensive user-centered design methodology that aligns business goals 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 integration functionality, of enterprise applications and data2 (703) 584 – 8949 www.navigationarts.com @navigationarts
  3. 3. Agenda• Requirements Overview• Requirement Types & Samples• Translating Requirements to Specification / Development• Requirement Activities• Drupal Requirements• The Business Analyst & Drupal• Functional Re-use• Requirements & Contributing back to the Open Source Community g y3 (703) 584 – 8949 www.navigationarts.com @navigationarts
  4. 4. Requirements: What are they good for?Sorting through the baggage• Requirements != Bureaucracy when done intelligently• Describing something complex should be easier/faster/cheaper than actually building it – when using the appropriate level of abstraction• It’s about the right p p g g people giving the right input at the right time g g p g• Promoting mutual understanding• 75% communication, 25% d i ti documentation – should b th product of t ti h ld be the d t f communication, not the means of communication• Keep the docs interesting, meaningful, digestible and productive – a interesting meaningful digestible, means to explain and educate4 (703) 584 – 8949 www.navigationarts.com @navigationarts
  5. 5. Requirements: The Case Against• We don’t have the time or budget to document requirements• Seems like too much paperwork, let’s build something already!• Our 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 like t change our minds We lik to h i d5 (703) 584 – 8949 www.navigationarts.com @navigationarts
  6. 6. Requirements: The Case For• Taking planning seriously, adding some formality, mitigating risk – meeting the formality of your clients/stakeholders• Doesn’t assume we are all talking about the same thing or speaking the same l language, l leaves a paper t il ( d not j t a cluttered i b ) trail (and t just l tt d inbox)• Describing and agreeing to the end state before it’s done (for clients or your internal business teams) documenting scope for budget/resources teams),• Agreement to the outcome - how do we know when we’re done?• Managing change - being on the same page as your project sponsors/clients6 (703) 584 – 8949 www.navigationarts.com @navigationarts
  7. 7. Requirements Overview• A requirement is a description of what the website will do.• A requirement can consist of a text description or a visual representation (annotated wireframe, design, model, diagram) – whatever it takes to get the i t th point across.• A requirements document is a collection of consistent requirements – can describe 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 the highest level or risk can occur (using your time wisely)• Defines the boundaries of the website/system. Helps avoid scope creep. y7 (703) 584 – 8949 www.navigationarts.com @navigationarts
  8. 8. Sample Model: Integration Diagram p g g8 (703) 584 – 8949 www.navigationarts.com @navigationarts
  9. 9. 9 (703) 584 – 8949 www.navigationarts.com @navigationarts
  10. 10. Warning: Abstraction Ahead• Talking abstract concepts about an abstract system – using language• A picture is worth…a lot• Know your audience, and your risks• Avoid documenting the documentation – when you have g y documentation 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 (703) 584 – 8949 www.navigationarts.com @navigationarts
  11. 11. Types of Requirements11 (703) 584 – 8949 www.navigationarts.com @navigationarts
  12. 12. Business Requirements• Aligning the business goals to the project• Very useful for prioritizing functionality and defining phased approaches• ‘How do you envision success for the project and how is it measured?’ How measured?• Drupal: The value of Open Source Technology• Drupal: Leveraging all available modules/code• Higher Ed examples: More applicants, updating the brand, more efficiency/easier maintenance, SEO based redesign, i ffi i / i i t b d d i increased l d level of l f 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.12 (703) 584 – 8949 www.navigationarts.com @navigationarts
  13. 13. User Requirements• The User Experience (UX) – aligned to the business goals of your organization• Think from the outside in, empathize with your website visitor’s point of view i• Defining your audience segments, their needs/concerns, what tasks do they need to complete• ‘What relationship does your organization have with your visitor segments (donors, members, investors, consumers, partners)?’ partners)?• Informing your Information Architecture / Sitemap / Taxonomy• Going from the analog to the digital, eventually into roles & permissions13 (703) 584 – 8949 www.navigationarts.com @navigationarts
  14. 14. Higher Ed User Segmentation Example • Alumni • Prospective Student – Undergraduate (18-22) (18 22) • D Donor • Transfer Student – Undergraduate (18- 22) • Parents of Prospective Student (18-22) ( ) • Prospective Student –Undergraduate (22+) (9 credit) • Current Faculty • Prospective Student – Graduate – Full • Prospective Faculty Time • Prospective Student – Graduate – Part • General Public Time • Current Student • Prospective Student - Non-Accredited Adult Learner • Industry Executives/Corporations • Prospective Student - Online • International Students14 (703) 584 – 8949 www.navigationarts.com @navigationarts
  15. 15. Use Cases Sample: Add SharePoint Service Goal 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 non-resource 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 3. Custo e d Customer Administrator selects the End User t ey want to st ato se ects t e d Use they a t add the SharePoint service to. …15 (703) 584 – 8949 www.navigationarts.com @navigationarts
  16. 16. Functional Requirement Sample – High Level16 (703) 584 – 8949 www.navigationarts.com @navigationarts
  17. 17. Functional Requirement Legends17 (703) 584 – 8949 www.navigationarts.com @navigationarts
  18. 18. Functional Requirement Sample – Detail Level18 (703) 584 – 8949 www.navigationarts.com @navigationarts
  19. 19. SJU Functional Annotation Example19 (703) 584 – 8949 www.navigationarts.com @navigationarts
  20. 20. Tech / Non Functional Requirements (NFRs) • Be afraid, be very afraid • Performance requirements – baselines, internet connection speeds, geographies • A il bilit requirements Availability i t • Security requirements – keeping Drupal patched! SQL injections, cross site scripting, hosting infrastructure security vulnerability assessments scripting security, • Capacity requirements • Analytics • Compliance • A bucket for anything you want other technical stakeholders to review20 (703) 584 – 8949 www.navigationarts.com @navigationarts
  21. 21. 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 projects. 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 planningThe 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.x21 (703) 584 – 8949 www.navigationarts.com @navigationarts
  22. 22. Progressive Enhancement / Responsive Design• The employed CSS3 techniques shall be employed as progressive enhancement, providing the richest experience to modern browsers, while still making an effort to accommodate older, less capable browsers.• T k screenshots of your websites in IE7 – show no d Take h t f b it i h drop shadows, no h d rounded corners and give your clients a piece of mind ‘that it won’t be that bad’.• Responsive Design• Leverage any docs on drupal.org22 (703) 584 – 8949 www.navigationarts.com @navigationarts
  23. 23. Aligning 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 community23 (703) 584 – 8949 www.navigationarts.com @navigationarts
  24. 24. 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 document24 (703) 584 – 8949 www.navigationarts.com @navigationarts
  25. 25. Translating Requirements to Specification / Dev• 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 config settings for each Naming conventions Our CMS spec is used in conjunction with PSD files and requirements docs; it does not live by itself.25 (703) 584 – 8949 www.navigationarts.com @navigationarts
  26. 26. NMWA Example CMS Spec26 (703) 584 – 8949 www.navigationarts.com @navigationarts
  27. 27. Requirement ActivitiesGathering Requirements• Talking to the right people at the right time• Analyzing 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• Rinse and repeat Ri d tDocumenting Requirements – writing it downManaging Requirements – updating and change control27 (703) 584 – 8949 www.navigationarts.com @navigationarts
  28. 28. Elicitation: Moving the conversation forward• Do not avoid ‘how’ when appropriate. There are many levels of what -> how -> what -> how.• Do not try to stay at the same level of abstraction. If workflow cannot be d fi d early, b t a 3rd party API i t defined l but t integration is confirmed, d ti i fi d document as t much detail as possible, as early as possible.• Work forwards and backwards what do we need to know to build the backwards, website• Use 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.28 (703) 584 – 8949 www.navigationarts.com @navigationarts
  29. 29. Drupal 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 copy29 (703) 584 – 8949 www.navigationarts.com @navigationarts
  30. 30. Workflow Advanced30 (703) 584 – 8949 www.navigationarts.com @navigationarts
  31. 31. Structured vs. Unstructured Content vs• Has significant implications to the maintenance of the website• 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.31 (703) 584 – 8949 www.navigationarts.com @navigationarts
  32. 32. WYSIWYG vs. Plain Text vs• Corresponds to structured / unstructured data• Is really the crux of the User Experience of the back end32 (703) 584 – 8949 www.navigationarts.com @navigationarts
  33. 33. CKEditor Customization• Re-use when possible, even for training documentation33 (703) 584 – 8949 www.navigationarts.com @navigationarts
  34. 34. Taxonomy• Often based off of our Information Architecture work• Use requirements for internal teams and stakeholders to start thinking in Drupal, establishing a common vocabulary• Use a Spreadsheet: • Vocabulary Name y • Vocabulary Description • T Taxonomy Primary Terms Pi T • Taxonomy Secondary Terms • Content Types applied to34 (703) 584 – 8949 www.navigationarts.com @navigationarts
  35. 35. Block Configuration & Reusability• Identify re-usable blocks in initial visuals (low fidelity wireframes).• Need to think about modularity early35 (703) 584 – 8949 www.navigationarts.com @navigationarts
  36. 36. D6 to D7 Migrations• Functional Analysis: what has to stay, what has to be added, what is deprecated.• Content type inventory• Custom module inventory• Functional to D7 module mapping pp g• Content migration strategy36 (703) 584 – 8949 www.navigationarts.com @navigationarts
  37. 37. The Business Analyst & Drupal• Strategic: creatively figure out how to help projects succeed. Strategy and ideation is fun – but this has to be grounded in technical reality• Helps to have a development background (and to know Drupal, even from a power user standpoint) t d i t)• Helps to be an extrovert, likes to communicate and explain technical concepts to non-technical people non technical• 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 patterns37 (703) 584 – 8949 www.navigationarts.com @navigationarts
  38. 38. Functional Reuse for Client Services• The BA and Drupal Lead should know what the development teams are 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 multiple projects, establish process for updating38 (703) 584 – 8949 www.navigationarts.com @navigationarts
  39. 39. Contributing Back• Requirements & Contributing back to the Open Source Community• Visual examples• The community can contribute with documentation and examples not just examples, code.• Requirements section on Drupal.org? q p g39 (703) 584 – 8949 www.navigationarts.com @navigationarts
  40. 40. Q&A• Open FloorConnect with NavArtsCall: (703) 584 – 8949Tweet: @navigationartsEmail: sales@navigationarts.comVisit: www.navigationarts.com www navigationarts com40 (703) 584 – 8949 www.navigationarts.com @navigationarts
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×