Where do web projects come from? This used to be something you just didn’t talk about in mixed company. Sometimes a website would slip away - claiming to be visiting a great aunt or working at an overseas mission - and return looking ‘refreshed’, revived and… well, simply glossy and glowing!
It was only a few years ago that I remember reviewing requests for proposals asking basically for “a web 2.0 makeover”. When user centered design started to become mainstream, the requests expanded to, “a design refresh and a side order of ‘make the site easier to use’”
“Requirements are initiated by senior managers and company executives as policies, aims, objectives and other high-level statements of intent. This necessitates considerable scoping activity as requirements start with vaguely expressed intentions and users’ wish lists...”
~ Usability in Government Systems: User Experience Design for Citizens and Public Servants by Elizabeth Buie & Dianne Murray
Likewise, when stakeholders come from a variety of backgrounds and multidisciplinary groups, submitted requirements documentation can be varied and inconsistent - from a 30 thousand foot view, to incredibly granular - often with a focus on a few key features combined with sweeping high-level passes at others.
How can we collect requirements expressed subjectively and document them in a quantifiable, actionable and measurable way?
Every web project begins with some sort of requirements gathering processes. Sometimes it’s done by a technical team, sometimes by a business strategist or marketing department. Needs typically seem straightforward to the people closest to the project because of personal pain points they’ve experienced with the web application. Many stakeholders will talk about how very obvious the need for improvement is. But how are these expectations turned into a well-documented, actionable build plan?
What are the challenges involved in collecting requirements?
Typical requirements gathering activities are business analysis, stakeholder interviews, reverse engineering current systems, wireframing and brainstorming with a goal to:
- Identify project objectives and limitations
- Identify critical success factors
- Define project deliverables
- Define the schedule of workshop activities
However, in An Early Start to Testing: How to Test Requirements (originally published in 1996) - Suzanne Robertson describes how there are actually three distinct categories of requirements:
- Conscious Requirements - Problems that the new system must solve.
- Unconscious Requirements - Issues already adequately addressed by the current system, and important not to overlook or dismiss!
- Undreamed of Requirements - Items that would be considered important if it was known they were possible or if they were better understood.
"Instead of buying a product, the customer buys the satisfaction of a need".
~ Peter Ferdinand Drucker
Successful requirements gathering focuses not only on the requested solution, but on uncovering unstated problems.
“The idea of human-centered design is crucial – the real goal of an engineering process is to improve human activities in some way, rather than to build some technological artifact…. In seeking to describe the purpose of a computer system, we need to look beyond the system itself, and into the human activities that it will support. For example, the purpose of a banking system is not to be found in the technology used to build such systems, but in the business activities of banks and day-to-day needs of their customers. The purpose of an online flight reservation system is not to be found in the details of the web technology used to implement it, but in the desire by passengers for more convenient ways of booking their travel, and the desire of airlines to provide competitive and profitable services.”
~ Steve Easterbrook, What is Requirements Engineering? 2004
The concept of uncovering value is not unknown to most multidisciplinary groups, why then is it so difficult to create strong requirements documentation with a 360 degree view of both business, technological and user needs? Because requirements gathering is a complex,creative process with many pitfalls…
When good requirements go bad… eight dangers your mama never told you about.
1. The Wallflower (overlooking a critical requirement)
No one can remember bringing it up during planning - it was just such a big, obvious piece that everyone just figured it would be included somehow. Only it wasn’t included in the requirements documentation... and therefore didn’t make it into the estimate, scope, project planning or build. In fact, its absence wasn’t even really obvious until user acceptance testing when someone said, hey guys, how are we handling ‘that thing’?” Unfortunately, often the only way to accommodate an important attribute at a later date is to re-architect and re-code. Ouch.
2. The Keener (inadequate customer research)
The concept of market research is a much more familiar and accepted one than requirements gathering. Often, much of this type of customer engagement and information gathering is likely already being collected and used by the organization to identify and define marketing opportunities and evaluate marketing performance. But they decided not to engage users for this project because it would just… take… too loooonng. “We just really need to get started”
Only they won’t discover if they had the right idea until the customers attempt to use the system.
3. The Techie (modeling only functional requirements)
Requirements gathering practices have historically focused on functional requirements - the things systems are supposed to do because functional requirements are the most obvious ones. Because writing requirements for a technical project can seem intimidating to non-technical folks and appear to be something ordinary mortals should not be able to do, an organization might task someone from the IT department or at least their most technical person to come up with a requirements list based on their understanding of system needs.
4. The Philosopher (recording attributes without adding context and meaning)
The Philosopher loves to evangelize and inspire. He’s epic at rallying support for his ideas, “the application should be easy to use, the system should be scalable, reliable, secure, robust, innovative, cool, fun, modern, young, hip…” How is it possible to object to the request for a ‘modern’ website? When there is no further context or explanation of what ‘modern’ means to stakeholders and users? You might as well ask for a ‘totally cool website that pops’. ;)
5. The Firm Stance (refusing to compromise or prioritize)
Everything is equally important, but some requirements are more equal than others. The Firm Stance doesn’t realise that some requirements will tend to contradict each other - despite requiring them not to. For example, making a mind-bogglingly complex access control system ‘intuitive’ and for a modest budget just might not be possible. It’s important to take into account the trade offs in the priorities chosen. Dedicate some time to negotiating the inevitable tradeoffs among conflicting attributes or business logic.
6. The Rush Job (not inspecting and updating requirements)
The cost to remove defects in requirements increases exponentially with time, inspecting your requirements models is the most effective way to identify ambiguities, unstated assumptions, conflicting requirements, and other defects at the earliest point. Then plan to return to the documentation at each milestone to review key pieces in case requirements have shifted over the lifecycle of the project due to external events (eg. introduction of new third party tools or a business merger adding a new division, etc.).
7. The 4th Draft Master Version NEW (aka the Perfectionist)
Attempting to perfect requirements before beginning construction is not as helpful as it might seem. Some design and construction activities are needed before you can tell how complex the project will be and how much effort each piece will require. Finding ways to test out your ideas is a worthwhile effort, as this really helps shine a light on shaky or incomplete requirements. Make it your aim to identify areas of uncertainty and move on, designating someone responsible for closing the knowledge gaps as you move forward.
8. L'Artiste (representing requirements in the form of visual designs)
If you Photoshop before you workshop, you run the risk of defining an interface solution that might not be the best one to implement. This undermines your ability to validate the chosen system because you are specifying the problem you hope to solve in terms of how you intend to solve it. It makes matters worse when you use filler text and placeholder images because it’s difficult to tell what contextual information will be needed with Lorem Ipsum. (source)
Requirement Engineering is still an emerging field, but there has been significant research and literature written on the subject. So...if you’re not a requirements analyst, what can you do (short of pursuing a certification in Requirement Engineering) to make your organization’s requirements gathering process more effective?
A move towards a more structured architecture requirements, modeling and systems design process.
The five elements of the requirements framework are Requirements Elicitation, Requirements Analysis, Requirements Validation, Requirements Documentation and Requirements Management.
"Software systems requirements engineering (RE) is the process of discovering [underlying] purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation". Nuseibeh and Easterbrook (2000)
Introducing elements from a seven step requirements gathering process can make a significant improvement in the quality of your requirements documentation. The steps are:
- Scoping
- Fact Gathering and Research
- Analysis
- Modelling
- Validation
- Trade-off Analysis
- Negotiation
So far we’ve defined the inherent challenges of Requirements Gathering and why a better process is desperately needed, and shown you a sneak peek of a more structured approach.
In part 2, ‘Designing the Solution’ we will explore each of the seven steps in greater detail.
~ Vanessa Turke is Director of User Experience and a Senior Project Manager at Drupal Connect