Add new comment
Want to learn more about Acquia’s products, services, and happenings in the Drupal Community? Visit our site: http://bit.ly/yLaHO5.
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.
Join Acquia and guest presenter Navigation Arts for this upcoming webinar where we explore best practices in project communication and associated requirements to support successful Drupal projects. Attendees will hear about:
Attendees will hear about:
• 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
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, and Web Managers.
Female: Hi everyone. Thanks for joining the webinar today. Today’s webinar is Requirements & Drupal: Planning for Successful Projects, with Jon Riekse, who’s Director of Business Analysis and R.J. Townsend, Manager of Drupal Solutions at NavigationArts.
R.J. Townsend: R.J. Townsend with NavigationArts. I have been working with Drupal for about six years now and working with NavigationArts for about a year. I lead the Drupal practice here and a small team of Drupal developers.
Jon Riekse: Hi. My name’s Jon Riekse. I’m the Director of Business Analysis for NavigationArts. I’ve been a developer in the past. I’ve worked with Drupal for about four years as a PM and a BA.
Thanks for everyone’s time today. I hope you really get a lot out of this presentation. I’ve been focusing just on requirements for about three years and I hope we have some good stories to tell, lessons learned from our requirements and build practice with Drupal here.
I’ll go ahead and get started. Feel free to ask questions through the presentation. We’ll try to respond as topics come up here.
All right. A little bit about NavigationArts, the market position, we are unique in the web space in the sense that we practice User Experience Design and Technology Consulting and really specialize where these systems and specializations overlap here as the diagram shows.
We focus on a user-centered design methodology that aligns business goals with user needs creating user experiences that drive enterprise value. We definitely take a user first approach as we think about requirements and then specifications.
The agenda for today is Requirements Overview. I’ll probably try to get through this pretty quickly, unless there’s a lot of questions concerning types of requirements, business user, etc. Then we move on to Requirement Types and Samples. Typically, when I’ve done this, a lot of people are most interested in the sample of documentation of requirements. Then R.J. will talk a bit about Translating Requirements to Specs and Dev and we want to talk a bit about the iteration between these two activities because that’s where you really get the most out of Drupal is aligning to what Drupal does best. Requirement Activities, Drupal-specific Requirements, the Business Analysts … sorry, (laughs) Analyst’s Role in Drupal. I should know my title now. It’s a maturing role. I think in the web space, they started to pop a bit four, five years ago and I think they’re vital so I’ll talk a little bit about that. Functional Re-use and then Requirements, Contributing back to the Open Source Community.
All right. Requirements: What are they good for? A lot of baggage around this term, kind of a lot of people think bureaucracy. I’m going to write stuff down. I want to build something already. What are we doing with all this paperwork, right? We’re developers.
The second bullet there is describing something complex should be easier, faster, and cheaper than actually building it when using the appropriate level of abstraction. It’s about the right level of detail. It’s also about the right people giving the right input at the right time. If we’re planning a big design and the approvers of that design aren’t involved early, well, you might go down the road a bit before you realize you have to change that and its significant impact to the rest of the project. Same thing with critical requirement, architecture decisions, try to get the right decisions made early.
Promoting mutual understanding, this is a big part of my job. Typically, you might work with clients or you have business stakeholders who don’t know a lot about technology. You need to talk with them and make sure the expectations are aligned about what you’re going to build and they know what they’re going to get out of the project. I see this as 75% communication and 25% documentation. The requirements should be the product of communication, not the means. Samples and the actual deliverables are extremely important and that might be why you’re on this call. You might have an upcoming deliverable you’re working on, but communication is really key here so I hope I get that across throughout the presentation.
Keep the docs interesting, meaningful and digestible, and productive, a means to explain and educate. This is the challenge. If you come out of a project with 100-page word doc that’s mostly text, you typically are not going to get a lot of response to it. It’s just too large. Diagramming is really helpful, modeling, and any visuals you can put in there. I have some examples here.
All right, The Case Against, we don’t have the time or budget to document requirements. Well, when something’s not what people expected in the development and you’re changing things, you don’t have the time for that either.
Seems like too much paperwork, let’s build something already, definitely understand that.
Our project is too small to necessitate requirements. My case against that is just do a couple pager. Do a two-pager if you need to. Just outline scope and the detail where you need to.
Our project is too large to necessitate requirements. We will never know everything until we start developing. Related to that is we use agile. Around that, but the view we take, we do waterfall. We do agile. We do a lot of hybrid methodologies, but when we’re thinking about the user experience, we kind of need to back up and get the big picture of what the website’s going to do to really architect, for example, high-level site map. You need to kind of bound and understand the whole system and especially from an architect standpoint.
If you’re using agile, I’d say start with some high level requirements. Understand all the scope. Understand kind of at a high level what you’re doing and then drill in as you’re doing each spread as needed if that’s the approach you’re taking.
All right, Case For, taking planning seriously, adding some formality, mitigating risk. Mitigating risk is really what a lot of this is all about, aligning expectations. For some of you, if you’re in an agency, sometimes you have to meet the formality of your clients and stakeholders. Maybe you’re doing a defense contract or something for the government and you might need this documentation just to kind of not only give them the door, but to keep the project on track and keep everybody agreed on the progress and formality of the project.
Question real quick about agile and contracts, how do you get the customer to embrace an agile delivery contract? That’s definitely I’d say an important question. When you’re contracting and scoping, a lot of the reason waterfall is so still common now and the kind of agency contract space is because you’re saying this is exactly what we’re going to do and this is how we’re going to do it. You’re getting approval, gate keep so you know you’re not moving onto spec ‘til requirements are done or ‘til visual designs are done. Agile can be a little hard because it’s about changing priorities and adjusting as needed and that is contractually hard to do. Joseph, maybe we can take that at end. That’s definitely … maybe you need a longer answer there.
All right, the second bullet point on this slide is it doesn’t assume we are talking about the same thing or speaking the same language. This is what can bite you if you don’t write things down is you’re doing a lot of talking and you think you agreed with the client. The client thinks they agreed with you, but yet at the end or when they first see a prototype or they first see completed code, it’s not what they expected. The documentation is the risk mitigation there.
Leaving a paper trail, a lot of what I do can be about consolidation, organization, and hopefully, clarity. If any of you have experienced I have an inbox and that’s all I have and that’s my documentation. It’s pretty tough to manage, especially with a multi-developer team.
Describing and agreeing to the end state before it’s done, definitely important for scoping.
Agreement to the outcome, how do we know when we’re done? In the quality assurance phase, how do we know when we’ve met the requirements and the system is bug-free and we’re not talking about feature changes?
Then managing change, being on the same page as your project sponsors, your client. Really, really important when you talk about waterfall, we’re not in the day and age of nailing down requirements for six months and then building for six months without change. Change with websites can happen every day, every week so you need to manage that change. You can't always resist it. You shouldn’t resist it. You should figure out how to manage change, look at impact, and look at level of effort and communicate that in a straightforward and honest way to your stakeholders or clients.
All right, Requirements Overview. A requirement is a description of what the website will do and we can use shall statements or natural language, but this is the outcome we expect. It can consist of a text description, visual representation. It can be an annotated wireframe, design, model, diagrams, whatever it takes to get the point across.
A requirement document is a collection of consistent requirements. You can describe the same thing a few ways to ensure the client knows what you’re talking about. Consistency is huge. If you have … example I use a lot is maybe you have a wireframe with an advanced search link and that’s it. You don’t have the advance search documented. You don’t have anything around there. Your stakeholder might say, “Great. I can't wait to get that advanced search.” Really, it was just a link left in and that can cause a whole lot of confusion there.
The goal is to describe as precisely as possible what is to be built and giving more attention to the most complex aspects, where the highest level of risk can occur, using your time wisely. This is where I think it can get a little trick, too. You might want to describe that global header is going to be on every page or talking about global elements, and maybe a little bit too much. Really what you want to be focusing on is this advanced three-step form and what the job script’s going to do, what fields are required and what happens with business logic. Really focusing on the right pieces is key here.
Defining the boundaries of the website system helps avoid scope creep.
Around that, here’s a sample I have for an integration diagram and this comes back to modeling is important. I could describe this with probably a couple of paragraphs of text or a huge bulleted list, but I don’t think it would be as effective. This is how we think about initially bounding a scope of a system. I know I have this website here and on the left, I’m integrating with a database and a geolocation service. On the right, I know I have a social media integration that I’m dealing with. This is just a good way to look at the big picture and for everybody to conceptualize what we’re about to do here.
R.J. Townsend: One of the things that I would say as I’m working with Jon and helping to kind of map out how a diagram like this fits into Drupal and some of the both core and contrip modules that are available, that’s where I come in to requirements and I say, “Hey, we’re looking at this geolocation service. Well, there’s these modules available and these modules have these core components available.” I’ll talk to Jon about, “Hey, these are the modules that are available that’ll help you define your requirements.”
Jon Rieksi: Great. Yes. David has a great question, then I’ll get to here about requirements and technology agnostic here.
Here’s another sample in here. I know I have a CMS. Here’s digital asset management system I might integrate with, just another example of looking at the big picture there.
All right, Abstraction Ahead. All right, this is where (laughs) you can't get out of this unfortunately with requirements. We’re talking about abstract concepts, about an abstract system using language. Use pictures. Know your audience and your risks. If you have a stakeholder that doesn’t know a lot about say email versus RSS or something along the lines that’s a little more sophisticated, you might want to explain that and concentrate on that piece, if you’re seeing questions or some comments from your stakeholders where things don’t seem to be really jelling here.
Avoid documenting the documentation. Software tools will help you here. When you start having too many traceability matrixes, too many artifacts, it’s really hard to be flexible and be agile in that sense. Depending on what the scope is and the complexity of a project, be careful of that.
Use common sense. Trust your intuition over the correct way to document requirements. This is a practical exercise of getting from point A, starting a concept to point B, being done with a quality project. There’s a lot of ways to go about this and just use your common sense there.
At the end of the day, if it doesn’t make the project better, it wasn’t worth it, and quality assurance definitely starts with this initial work here.
All right, a little bit of types of requirements and I’ll talk about David’s question in this context. Typically, you’re going to start with the Business Requirements and I think of that as the why. This could be at the executive level. Why do we need a new website? Why do we need this new feature of the website? Why do we need to migrate to Drupal? Are we going to save money? Is it the staff we’re looking at? Are we looking to kind of gravitate towards an open source model in general for Enterprise versus for example Microsoft Stack. This is kind of why the project is funded and the purpose of it. Sometimes we will come in, we’re at the kind of agency level where we’ll come in. Sometimes this will already be documented and really fleshed out. Sometimes we come at the strategy to figure this out. What are the KPIs? Why are we going to look into a new website?
I put technical req next. This is really an overlapping process. I put it here because before we really get too deep into the next steps, I want the whole team to know what are the constraints, right? To David’s question, maybe we’re definitely using Drupal 7. That could be something that was made as part of the project or maybe we’re definitely going to integrate with the sales force system or maybe the whole project is about … it’s already figured out as about getting mobile users to interact with the website. I’ll talk about this, but technical constraints are really important at this point in the project.
All right, user reqs, who and the what, and then functional reqs are definitely the what and you get to a good level of detail of what you’re about to do. Here’s where I think being specific to Drupal, it’s really, really important as opposed to a completely custom map where it’s kind of greenfield is about this process of aligning Drupal and what it does best to the requirements and really educating the clients on what modules are out there and the level of effort in particular.
Around David’s question, good requirements can definitely be technology agnostic, but kind of as I mentioned in the technical reqs and the constraints, sometimes we come and we know it’s going to be a Drupal project already. I’m already in this mode of aligning the requirements to what is in scope and in budget for Drupal. Maybe it’s not completely the kind of rulebook about how to do great requirements, but that’s when I try to get a little more practical and I might go, “Okay, we’re going to use Drupal. Let’s go ahead and align this as good as we can.” We can talk about that later, David, if that doesn’t quite answer your question.
All right, Biz Reqs, aligning business goals to the project. How do you envision success for the project and how is it measured? At this point, you might be talking about KPIs. You’re talking about increased visits. You might be talking about cost savings for the organization. For Drupal, I see it as the value of open source technology, free licensing. Let’s go ahead and leverage that. It might be a business requirement. Or leveraging all the available modules and codes that’s out there. You don’t have to buy. That’s user contributed. Very powerful reasons to use Drupal.
We do a lot in higher ed. Some business requirements here, more applicants to your university, updating the brand of your website, more efficiency, easier maintenance, SEO-based redesign, looking for keywords, increased level of satisfaction of prospects through the enrollment process, qualified applicants, etc. One thing you can do here that’s helpful is run a recurring survey. Some of these … sometimes you run into business requirements that are soft, can't be measured by hard numbers. It’s great to run a survey year over year, ask students, “How well did the website affect your decision to come to this university,” etc.
All right, User Requirement, this is really a specialty of NavigationArts. It’s really wonderful to be working with an amazing group of information architects. I learn something new on this aspect every day. Aligning the User Experience to the business goals of your organization.
Really helpful to think from the outside in, think from your user’s point of view, very hard to do. That’s kind of our specialty. We’ll come into an organization that’s thinking really from internally out. Maybe their website is built around their internal infrastructure rather than how users see them and needs there. We do redesigns kind of based on that point of view.
Define your audience segments, their needs, concerns and what task do they need to complete.
What relationship does your organization have with your visitor segments? Are there donors, are there members, investors? Defining that is helpful as a kind of step in User Requirements.
It informs your sitemap and your taxonomy, information architecture. I see this whole process really, as you’re going from the analogue to the digital, you’re starting out with these high level business goals and you’re getting things to a digital state with kind of requirements that are very clear and kind of binary, yes, no, they can be tested. That really helps the developers begin to think about a spec and a code, to have that level of granularity and organization in the planning.
Here’s some examples of Higher Ed User Segments. Students, undergrads, transfer students, prospect students, all have maybe some different tasks they need to complete, different concerns. Adult learners might be interested more in parking or the nighttime or weekend class schedule where undergrads are really concerned with the atmosphere and maybe even social aspects of university.
All right, Use Cases, not a huge fan. Sometimes I use them. Sometimes … because websites are often very nonlinear, doesn’t always get you there from the kind of user point of view, but if you have an ecommerce, highly transactional website, things that are kind of linear and steps, maybe even back in work flow, it can be helpful. I don’t like them that much so mine is based on a SharePoint Stack here, SharePoint Service so you need to have this in your toolkit. Some clients or stakeholders really want to see this. Certainly, a formality about doing business analysis here. I’ll talk about it a little bit.
This is a business use case as opposed to a system level where you might talk about things happening on the backend of systems talking to our ERP or the CMS updating another internal record.
Primary actor in this case is a customer administrator. You have a trigger. This is why this Use Case is initiated. You have a set of preconditions. The customer has Purchase SharePoint, etc.
You might have a preconditioned Use Case, like in this case they logged in. A post condition, they got SharePoint and then some steps.
These type of Use Cases I kind of blow out. You have alternative steps. You have exceptions. There’s a lot of way to go about this. It can become kind of a tangled web if you don’t keep it simple. You can extend Use Cases. You can include other Use Cases. It starts to feel like programming a little bit.
The question from Joseph, no, I definitely don’t always use it. I’m with you. I actually probably only use this on 20% of my projects at that. Oh, sorry, the question is about this use case graphic, do you always use it? It seems a bit overkill for a medium sized project. I’d agree, I’d agree, Joseph. Like I said, I keep this in my toolkit for advanced transaction functionality, but it’s kind of the exception here.
All right, here’s some high-level requirement samples, very high level. Maybe you’re using this as initial scoping or this is what you’re getting to think about your personal or development team estimate.
A couple things about this table. Important little housekeeping stuff, have a unique ID. This is very important to start early. When you come to QA, you really do want to say, “Hey, there’s a bug on FR 161. I typically use acronyms for functional requirements, FR, technical requirements, TR, that type of thing.
Then you actually have the requirement. At this point, it’s very high level, just think about scope. Prioritize requirements are great. This is how you can definitely get your stakeholders to think about what they really need. You can go ahead and align this to business goals, if there’s too much or too much outside the scope of what you get done in a certain time.
Then LOE here, and LOE, this is how I think about it with Drupal. On the left here, high level of effort requires significant development effort, may be completely custom coded in Drupal. You’re talking about customization here and if you all haven’t been down this road with Drupal, you want to know where you’re going to focus all your customization at. You don’t want to have the whole site not leveraging user-contributed modules or core modules. You want to pick your battles here.
Medium level of effort requires some customization to existing code base or to existing Drupal modules, but is not built from the ground up.
Then low, requires only minor customization to existing functionality. Hopefully, at this point you’re talking about config, Drupal config to get there.
Okay. A little more detail here. On this slide, at this point in this example, we’re talking about managing testimonials. In the second item, you can see we’re talking now about types so that the business stakeholders are helping me to find these types of testimonials and this will probably drive taxonomy in Drupal later. We talk about text and images. We talk about images being optional. The system shall support video integration, written testimonials. We’re getting to a level of detail that starts to be digestible from developers taking this and thinking about how they’re going to build this.
I have a question from Brent here. Where do you, if you have introduced translation into the requirements, would each FR or later as a separate FR? If you’re talking about localized content and translating content into German and Spanish, I usually have a different section for translations and it talks about the type of content that will be translated. It talks about translational workflow, how it’s going to integrate with maybe a third party service and workflow around that. Then of course, which languages. Then of course, the real big important one, can the client add new languages later? It’s good to think about that.
All right, here’s another example. We released a new website for St. Jo’s not too long ago. Some kind of advanced AJAX interactivity on the home page, definitely worth checking out and we documented this. This is an example of functional annotations. We’re looking at a visual, and I’m annotating it, and I’m describing the requirements of how it’s going to work.
This is really getting into spec. Some people might think of these as a functional requirements document or FST, a functional specification document, and you can adjust your deliverables as needed, but really this starts to get in the fact that we had some requirements, something was probably wireframed. We’ve now put visual design on it and now we’re wrapping up this level of detail to build it. You’re of moving into spec at this point.
All right, Tech/Nonfunctional Requirements. Be afraid, be very afraid and it’s all tongue in cheek, but not for the faint of heart here, experience, this comes back to the fact that you need technical input when doing these type of requirements. If I put these out here without talking to R.J. and the technical team about performance requirements, that’s going to be a bad thing. If we’re starting to say, “This is what someone with a broadband connection is going to expect across the country.” A lot of risks there. Be very accurate here.
Availability requirements, we’re thinking about how many nines. We’re thinking about infrastructure, server loads, server performance, failover. Security requirements, if you’re in a agency model, you’re typically going to provide these. I would never go to a technical client and say, “Tell me how secure you want your website to be, right? They’ll say, “You’re the experts. You tell us.” There are some special circumstances where you’re talking about just things like SSL, which pages and functionality have to be encrypted.
Capacity requirements, analytics, compliance, we’re near the DC area here so 508(C), government websites, big deal. Definitely figure this out before you do wireframes, before you do visual design. If you’re doing heavy interactions, then the main corporate website needs to be compliant. You need to throttle that down or come up with an alternate theme.
Basically, a bucket for anything you want other technical stakeholders to review. The way I think about this is I usually with my requirements documents, I will write a clear technical requirement section just to tell the client make sure your technical person reviews this and maybe not your marketing manager. You’re kind of guiding the client into who need to participate in the process, too.
All right, Device/Browser Support, at a lot of these recent Drupal events, looking at responsive design and kind of mobile first and everything around that, mobile and tablet requirements are causing a paradigm shift in how we think and plan for website projects. There’s no way around it. I think Drupal, its ability to get a prototype out there and think about it is really, really a nice angle as opposed to kind of custom code or some other CMS platforms that require a lot of customization before you see something. The days of “I have a PSD that’s 1,000 pixels wide and this is it. This is the design,” have come to an end, so I think we’re all embracing this change recently and moving into the future here.
IE6, IE7, here’s our take on that. It’s really almost always in the client’s best interest to receive modern maintainable code that is not hacked for older browsers, but verify this is the case. You might have a group, an organization that is using IE6 because they have an old CRM that requires IE6. Definitely find that out.
The first step is to look at analytics. I would never tell a client, “Don’t use an older browser,” until I can tell them, “You have 0.3% people on IE6. It’s time to kind of let them go a little bit.” The way we do that is progressive enhancement. Otherwise, graceful degradation using CSS3, HTML5, for an optimal experience while older browsers getting some semblance of the experience, maybe not the whole thing.
One way we’ve gone about this is take screenshots of websites we’ve done in IE7 and show that these HTML5 features or CSS3 features like drop shadows and rounded corner. This is what it will look like. It’s not the end of the world. It’s not going to break. That’s one way to get there.
Responsive Design, I have a screenshot of the Omega theme here. That’s one way we think about how to think about requirements and how to initially be built.
This is the slide about how we think about aligning those.
R.J. Townsend: Right. I’m going to talk a little bit about how in the process of working with Jon, how I helped to align the requirements that he’s gathered from the client to the functionality that is available within Drupal.
A lot of that is it’s this communication process of talking to the client about the benefits of using open source code. There’s code that’s available. There’s a big community of people around that help to support it. It’s quick. It’s fast. It’s license-free. It’s very valuable.
One of the things that you’re going to be able to do is through reusing your code. It’s going to help to reduce the time it takes to develop. It’s going to reduce any type of budget that it’s going to take to code.
Really, we have this 80-20 rule. We say, “Okay, if this specific module can meet 80% of the requirements as documented, and there’s going to take another 20% of us to do custom code or something like that, then that’s great.” We’ll say, “Okay, this module will meet requirements,” because in the end, hopefully we’re going to be able to build something that we can contribute back to Drupal, whether it’s a new module or a patch or something like that. Really, we’re taking a look at modules, asking the question does it fit, what can we do to make it fit, and can we contribute that back to Drupal?
Translating Requirements to Specifications, what we use is we use a document called the CMS tech spec and this is what we use to align these requirements to specifications. Obviously, it requires a thorough understanding of the client, the documentation that Jon has been working on and whether that’s a statement of work or wireframes or Photoshop files or list of requirements, requires a thorough understanding of that, and also a thorough understanding of not only how Drupal works, but the various modules that are available, where people are focusing their efforts on, which modules tend to be the ones that are going to last the longest.
Basically, the CMS spec maps out requirements to modules. Most, if not all, of your spec document and dev plan should be determined by the time requirements are approved. When Jon and I are working together, I know when we’re talking through requirements, we’re talking with the client, I know the direction that I’m trying to push requirements because in my mind, I haven’t mapped out, “Hey, this is the requirement. This is the module. This is how we’re going to do it.” Your spec document, it should provide framework for how the site will be built. CMS spec complements Photoshop design files and requirements documents.
Jon Rieksi: Yes, and a big kind of overriding topic of this is just getting the development input early enough when things are still being planned. That is just critical. It’s probably a little less waterfall in the planning of requirements are final and then you’re moving to spec, and I think we’re kind of agile, but in our way and should be with Drupal about providing those feedback mechanisms to allow solutions to impact kind of the beginning and thinking about it. As I tell some clients, requirements sound probably boring to a lot of people, but framing the problem leads to how the solution is built. There’s just no way around that. If you can be creative in how you think about your project and your problem, that’s going to influence the solution in most cases.
All right, thanks for the typo there. Someone had a question. All right. On to the next one here.
R.J. Townsend: Translating Requirements to Specifications, so our CMS spec documents, they’re usually anywhere from 75 to onwards of 200 pages. It is a complete documentation of all the content types we’re going to use, all the fields that we’re going to use, views, contexts, panels if you believe in those things, blocks, themes, boxes, beans, (laughs) I feel like I’m rhyming here, and also the naming conventions for each and then some of the required config settings as well.
For example, what tokens are you going to use for pathauto or what specific beans are you going to use for blocks or regions or what different contexts are you going to use depending upon if it’s a one-, two- or a three-column design?
We also talk about deployment architecture. How is it that we are going to number one, be developing internally and number two, how are we going to share that code with the client. Other times it’s more complicated. Let’s say you’re doing continual releases. The question is how, and what we discussed is how do you go about continuously releasing code in such a way that there’s little to no downtime and anything, any type of config settings that are done on the production site, you aren’t overridden by what we’re doing.
We also talk about required modules, whether it’s core, contrib, custom, features and also if you believe in features, and also the high-level config settings around that for each, and then a little bit of redundancy here, but naming conventions as well.
Our CMS tech spec, it’s used in conjunction with Photoshop files and requirements doc. It’s not a document that lives by itself. It’s very much when we as developers sit down and start building the site, we are continuously flipping between requirements and Photoshop files and in the CMS tech spec as well.
On this next page, we built the site for the National Museum of Women in The Arts and this ended up being … it was about 150-page CMS spec. I just included a snapshot here of what the table of contents looks like. You can see we started off with we have our table of contents. We have overview of what this document is. We talk about the organization of the document.
Then one of the things that we do is we talk about page types. A site can have anywhere from say 10- to 20- to 30-page types. You have your home page. You have your generic page. You have say a list of upcoming events. That’s going to be a page type as well.
What I’ll do is within this document, I will take that actual Photoshop file, put it in there and then annotate that with, “Hey, this header region is going to have these three blocks in it, B1, B2, and B3.” Then I’ll say, “In this entire home page is going to be controlled by this specific context and it’s going to have these views on it.” That’s the page types to technical components.
Then you can go through from that and see okay, here are the specific blocks and related modules to those blocks. Here are the content types that are involved with these page types. Here are the views. Here are the menus. It’s going through and on every page of the requirements doc and on every Photoshop file that we had, it’s mapping out the various components to what Drupal has to offer. Then you could see, we also use a couple appendices as well, if there’s any additional module configurations, any type of custom modules, maybe if we have content migration, some of these more … something that doesn’t happen on every project, might be isolated to a specific project.
Jon Riekse: Okay. I might take this time to address a couple questions that popped up here. From Joseph, when working with a customer, usually we do not own the servers. Any requirements you suggest on server infrastructure, especially for hosting providers?
There’s probably actually some good info on Acquia's site. They’re hosting. Things I look for up time, capacity requirements, encryption. Anything on your list R.J., you can think …
R.J. Townsend: I say one of the more important things on my list is just the ability to SSH into the server and to know that either I can have root access or at least pseudo in and get the various permissions to do things that I need to do on the server.
Jon Riekse: Okay, so management and the access you need to kind of …
R.J. Townsend: Exactly.
Jon Riekse: Sure.
R.J. Townsend: Then also we use an open source tool for deploying to various environments and really, I prefer that any type of server we’re going to be working on is able to work on with that tool.
Jon Riekse: Okay. An interesting question here from David Math, upon matching the elicited requirements to Drupal modules, if you find existing modules don’t quite support the desired functionality without a lot of customizations, how do you go about communicating the tradeoffs to your business clients? Thanks. Yeah, great question.
That’s really kind of core to what we’re doing here. Basically, trust and transparency just goes miles at this point in these conversations and hopefully, you’ve done good work and you’ve built a relationship that really allows that direct communication to say, “Hey, you know what, you have some interesting requirements for user generated content and the ability to upload this type of file, but this module we have for say updating a forum or kind of commentary model doesn’t quite support that. This is probably the level of effort, even a rough magnitude of what it would take or maybe we need some customization there.”
Then you talk about priorities and you can do that in the … that’s where business requirements, even though sometimes they might see … they could seem a little fluffy if you don’t have KPIs and strong measurements, that’s where it can really help out. “Tell us about a user uploading this file. How does that really fulfill a core business objective?” At this point, you’re kind of doing a little bit of that conversation, primarily with the business teams and not necessarily with the technical input, but you’re getting them to really prioritize and say, “You know what, this is important,” and if it was kind of not scoped first, if your scope was good in the beginning and you’re kind of … how you kind of priced or estimated it, you can make a good case, we didn’t know about this so it wasn’t in our estimate if it’s new.
If you kind of knew about it, but you just didn’t know the exact definition, then you say, “Listen, we’ve basically elicited a lot of requirements, a lot of new things, let’s go and prioritize and think about how much customization.” Let’s look at the 80-20 rule R.J. talked about. I guess to sum that up, it’s about prioritization at that point.
All right. Requirement Activities, with all this said, you’re a developer, project manager, you’re either starting a website that you know is Drupal or you don’t, and you said, “You know what, go ahead and document the requirements for this project.”
Let me talk about my process just a little bit here outside these bullets. What I do first is I take every piece of known information about the project and try to summarize it up and put it into groups. Maybe we know it’s Drupal 7. That’s a technical requirement and constraint. Maybe we know it has to support mobile devices. That’s a technical requirement. I know these are the high-level business goals. I document those.
I think about what I know about users. I think about what I know if anything about functionality. I take that list and I start thinking about questions. Maybe I know we need to play videos, but no video provider service has been selected. I start thinking about requirements to ask stakeholders around social. Is it important to get some social traction with your videos? Is it important to have HTML5 video playback? Is it important to support flash? Is it important to support related videos? I come up with a big list of questions for these stakeholder interviews.
Back to the slide here, it’s about talking to the right people at the right time. I might have a list that’s really about marketing angle. I have a list of marketing questions. Then I might talk to their technical team and ask them to tell me about their problems, issues they’ve had, concerns they have about supporting functionality or integrations, etc.
Then if the client has any documentation, analytics reports or other requirement activities or list of functionality, they want to go ahead and analyze that.
Ask the question different ways to ensure understanding. I might kind of slice and dice things a couple of different ways just to make sure the stakeholders are giving me information that backs itself up and is not contradictory. If I hear contradictory information, I’ve got to iron that out. That can really happen. If you talk to different groups of people, some people might want functionality A and some people want functionality B. Then what I usually do, I tend to try to get those two people in the same room and iron it out. If we can't figure it out together, I go up a pay grade and talk to the people that are sponsoring the project and then have them prioritize. That’s one way to go about it.
I write all this down and then I rinse and repeat. I might go six or seven iterations of this on a common project and every time, I’m getting a better level of detail. I just keep on finessing this, getting feedback, getting priorities, and getting to the point where the business is pretty happy with what they want out of this project, but in the meantime, I’ve gotten technical feedback. We’re aligning to that scope typically sometimes in the background the whole time. That’s how I go about it. Managing requirements is part of it. Updating and change control.
Moving the conversation forward, this is where we get into these requirement versus spec conversations that are really tough to kind of unravel sometimes. I don’t stick just to the requirements. I don’t avoid the how questions when it’s appropriate. There are a lot of levels of what, how and what, how.
A high-level requirement coming back to the video analogy is we need to play video. Well, if that’s into my requirement and then the development technical team have to take that over for a spec, they don’t have a lot to work on. Through requirements I might figure out, “You know what, we’re going to use YouTube or we’re going to use Bright cove,” and then there’s follow-on questions that come to that. “Okay, you’re going to integrate with YouTube. Let’s think about how that’s going to work. You need to have related videos for Bright cove.” We start thinking about the different formats and maybe they’re going to display based on taxonomy and think about those relationships. I just keep on drilling through. I think it’s the most efficient way for the second bullet.
I might not know workflow, but I know this third party API integration so I’ll write that on the same document. Now this kind of goes against our nature of trying to keep documents the same level of abstraction. I just don’t try to go there. If I know things, I keep on pushing, just try to get to the end goal.
Work forwards and backwards, this is where development experience can really help you when you have requirements. You know with the developer what information you need to build it. I try to think about that when I get to the end game there before … as I’m moving along the process.
Here’s the key point. You have to use your brain and experience to realize if you are making too early an implementation assumption. Like my goal for R.J. and his team is a lot of what they need to do with a spec can be done without going back to the stakeholders and opening backup scope and requirements. That’s the type of thing I’m trying to get consistent. If we have to go back later and we miss something or it wasn’t bounded and there’s a contradictory requirement, we might be in the middle of development and now we’re accidentally opening back up a question that might have severe impact to flow through all sorts of other areas of developing the site. That’s where you can get hurt if you miss something. Important to kind of be diligent. Make sure you have a whole solution that is not contradictory.
I’m going to go ahead and answer some questions here. Let’s see, the one came in from Joseph Hurtado. Any experience with the cloud providers? R.J., would you like to take that one?
R.J. Townsend: I think there are a lot of cloud providers out there that provide Drupal specific services. Obviously, Acquia is one of them, Pantheon, seen a number of other ones out there. Some of them even offer tools that help you through the deployment/staging process. There’s definitely some good providers out there. There’s also some shady providers out there.
I always say go with the good name brand that you hear, that you trust. Talk with your colleagues, with other people about, “Hey, have you heard about so and so? What’s their reputation like?”
I think the only … I want to go back to what I have, requirements in a server, just make sure that you have SSH access and that if you’re going to have to … let’s say there’s some type of special script or program that you need to have running, just make sure that you have these requirements documented and that any type of hosting provider you go with is going to be able to meet those requirements.
Jon Riekse: Okay, great. Next from Randy, what experience do you have working with nonprofit membership driven heritage preservation organizations?
We in NavigationArts have a ton of experience working with nonprofits, certainly, the membership driven model of you have a member log-in and there might be something around donations or e-commerce with membership fees and special functionality from members. I don’t have a lot of direct experience I think with heritage preservation organizations, but maybe Randy for that specific question, if you could send us an email, we’d be glad to get back to you.
Leslie, great question. What level of Drupal expertise do your BAs need and how did you get them to that level?
Well, that comes back to the technical background. It’s great to have BAs that have done web development of some capacity, are familiar with Drupal, maybe have been a web master, understand configuration, a little bit about what’s happening under the hood. What we do here is a lot of internal training. It’s all about Drupal knowledge transfer. R.J. gets to do a lot of that here.
I had the luxury of listening to Kiran Lau a couple of years ago about him speaking about Drupal, Drupal 7, Drupal 8. He’s part of Acquia. He talked a lot about Drupal has had huge success in the technical community, but the future of Drupal is about getting that information and knowledge back to the business community so project managers, business analysts, stakeholders, people funding projects. A lot of what I’m talking about is around that aspect of moving out of technology into the kind of business community and communicating that out.
A lot of training, there’s a lot of things you can do with BAs for different aspects of their work. BAs can help with QA and they’re going in there and helping QA to back-in so maybe they’re moving some blocks around and learning about that way. BAs can help with content entry and just getting to the Drupal camps and reading about it and if they’re technical enough to even play with the hosted version and try a little bit out themselves. That’s great.
From Judy, how do you get clients to write content in a timely manner?
I might have to take that one off line. That’s a long … that’s a great question and giving a discrete content entry phase for them to prepare for that and spreadsheets that model your content types is very important. I’ll be glad to follow up that through an email if you like.
All right, I’m going to get through a few more slides before I move too much further along with the questions. Yes, we’re … kind of a time check here.
A couple of Drupal specific requirements, simple work flow. All right, common one, workbench maybe for Drupal 7. I had some problems with the revisions and things for Drupal 6. I look at this and go, “This is a great workflow. This is an easy one. Let’s define some email copy and we’re good to go.” R.J., what’s your perspective on this one?
R.J. Townsend: I think you definitely want to align that to what’s available as far as contributed modules because this can be just a very deep rabbit hole.
Jon Riekse: Okay. An even deeper rabbit hole is here’s an example of another one we did. I look at this and go, “Let’s make sure that this is what the business needs. We have corporate review. We have other departments involved. A complex work flow, so let’s make sure this is worth the energy to pull off.” What’s your take, R.J.?
R.J. Townsend: Once again, just make sure you align it to what is available and I think that’s a lot where I’m going to come in and I’m going to say, “Hey, this is what, for example, the work bench module, this is what’s available within the work bench module. I know this is what the client is requesting, but if we can kind of shift our model or do something just a little bit differently, we’re going to be able to meet that 80-20 rule.”
Jon Riekse: All right. This comes up a lot in requirements. Me and R.J. kind of go back and forth about how much of this should be in requirements and how much is spec. I take the user’s point of view and in this case, it’s the Drupal admin user of it’s very different to edit a page that’s a big block of WYSIWYG versus having structured data around defining my content type and my content entry has a discrete date field, a title field. I don’t need to know HTML, all of that type of thing. It has significant implications to the website. Do your content people know HTML? For me, when we think about content types, this affects the other page types and modularity of the whole system. I’ll keep moving along here as we’re running out of time.
One quick thing for structured data, what fields are included? Sort orders for list, min/max, number of elements, what happens if there’s nothing, descriptions of empty results sets. We always want to know that, right? What if you have a page and there’s four content types and all of them are zero, right? Think about that and controls for paging and filtering large sets of data.
Here’s an example of WYSIWYG versus plain text. Something we did for the National Aquarium. You’ll see the annotation number four is rich text. We expect them to put in their WYSIWYG editor, they could do HTML, but they might pick if it’s going to be red or green or italicized. In contrast, on number five there, you’ll see a button and basically that will be plain text. They can't break it. It’ll always be a consistent file.
CKEditor, customization, just some things we’ve done here.
Taxonomy, I will say try to get your taxonomy into the Drupal language in the middle of the planning, really start fleshing out vocabulary names that match to Drupal.
Block Configuration, Reusability, if you think about this early, you can do usability … I mean reuse … if you don’t think about it too early and you have too many variations, you lose that modularity. It’s what we call here the unique snowflake approach. Try to avoid that.
We’ve done a lot with D7 migrations I’d say at this point. Call us if you need to. Functional analysis, content type inventory, you’re looking for a functional gap between current state and future state.
BA role & Drupal, talked about some of this. It can be creative in how you think about the problem. Got to be flexible. You can run some logic interference from your technical team, that’s probably usually pretty busy.
We try to use functionality between different projects. It really helps to build up this library. As you specialize, you specialize in Drupal. It’s nice to be able to reuse something you did from your last project.
Hopefully, contributing back. To the earlier point, I think to myself sometimes I know from a lot of people’s questions, they’d love this. What if you had a sample requirements for every user contributor module that you could just kind of copy and paste and start from there? Wow. Wouldn’t that be great. I hope we can get there by contributing there.
I’m going to go through a few more questions as we ran out of time here.
Caroline Mullen: Let me just jump in for a second. This is Caroline Mullen from NavigationArts. I just wanted to thank Hannah from Acquia and the rest of the Acquia team for allowing us to present today. Then a huge thanks to Jon and R.J.
We have ran out of time. We are running out of time so if your questions were unanswered, we’ll follow up with you via email, but feel free to send us an email at email@example.com or ask us questions on Twitter and we’ll get back to you over the next couple of days.
But I think you have time to answer maybe one or two more.
Jon Riekse: Okay. Yes, I’ll get through a few more. Good question about how much work is done from Dave before you sell or commit in some level to an estimate of your internal organization?
It’s great to have maybe a … if you’re coming in cold, we have sales activities that we typically take on to scope things correctly. If things need more work in a paid capacity, it’s great to have a discovery budget where you can come and do requirements work to get a better estimate for the build. That’s really ideal. Not everybody’s happy with that. I would say going back to one of my slides, you’re looking for high level functional scope at least before you commit I would say.
We’re doing a website. There’s got to be some forums. There’s got to be some integration with a third party. It really comes down to risk mitigation. Definitely more of an art than a science. We don’t do official requirements, but we do a scope, scoping done using on any spec work.
From Jason, would you offer any additional advice for preparing requirements for smaller projects? We provide grassroots advocacy service with often a rapid response with little planning.
My advice is back to doing the two-pager, three-pager if you need to. You don’t have to blow it out, but think about these high-level functional groupings and put just some bullet points under it. That’ll be my advice for you. We’re doing an e-commerce site. It’s going to support these type of products. Administrators will be able to update the products. There’ll be some text. There’ll be some shopping cart. At least get that high-level bullet list and then focus on the complex pieces with a little more detail. That’d be my advice there.
Mauricio asked is there a particular module that you use for AMS integration, IMS, I work a lot with these associations. I’ve worked some integrations with IMS from a .net based system. I can't think of … I know there’s some modules for association management systems out there.
R.J. Townsend: I remember looking that up not too long ago and I didn’t find anything that was very really production worthy.
Jon Riekse: Okay.
R.J. Townsend: That was a while ago.
Jon Riekse: There was a good presentation on this at Capital Camp in DC a couple of months ago. If you go to I think it was capitalcamp.com or .org, search their presentation. There was a good one I saw there.
From Eric, how would you work with a client who’s technical team has little to no experience with agile development or their nontechnical project team is particularly large?
Well, you don’t have to convince them to do agile. I’m fine with waterfall. As long as you’re doing the technical check-ins, I’m completely fine with waterfall if that’s what you need to do. I would say it’s pretty rough when you’re taking a client who’s non-agile and try to get into an agile methodology. It’s just sometimes too much of a culture change from my experience.
R.J. Townsend: Agree.
Jon Riekse: Okay. All right. That’s all we have time for. Anything about Drupal 8, etc., feel free to send us an email. We’re going to wrap up here. I know the slides will be posted soon. I appreciate everybody for your time.
R.J. Townsend: Yes, thank you very much.
Female: Yes, thank you. Thank you, Jon. Thank you, R.J. for the great presentation. We really appreciate your participating today and answering all the wonderful questions.
Thank you everyone for joining us today. Again, the slides and recording will be posted in the next 48 hours to acquia.com so you can find them there. Thank you.