The hardest part of getting started on a new project is organizing your thoughts. You’ve hopefully got a product/project vision, an executive summary, maybe even a competitor analysis or SWOT analysis, but where do you go from there? How do you get started?
Thinking strategically is different from acting strategically. The former is all in your head, while the latter requires careful execution and the ability to document and express your internal thoughts in a way that can be shared and understood across a team.
The act of writing feature requirements is a strategic one.
There are many ways to do it, and however you approach it, you’re likely to be biased in some way. Maybe your personal focus might be more towards the visual and UX side of things, or a past life as a coder might make you start thinking about integration tests already. There’s nothing wrong with this kind of bias, but you must be aware of it and remember that not everyone thinks the way you do. Use whatever approach makes sense to you and then translate into a format that will make sense for others.
Here are some typical approaches, that could be used to document such feature requirements:
User Stories
Telling a story about what you want a product or feature to achieve can really help a lot.
A story usually has a protagonist — the user — who finds themselves in a situation — the user flow — where they have to do something — complete a task — in order to achieve some goal or resolution — the expected outcome.
You might start by making a list of all planned features and then telling stories about each one from the perspective of the user. Each feature may have just a single story, or even several, depending on the use cases of the feature.
Not only do users help you to consider the experience from the user’s perspective, but also helps to identify expected outcomes.
- As a <user role>
- Given <some precondition>
- And <some other precondition>
- When <some action by the actor>
- And <some other action>
- And <yet another action>
- Then <some testable outcome is achieved>
- And <something else we can check happens too>
A key item there is <user role> — you need to have a very clear understanding of who your users are. Thinking about who your users are, documenting their personalities, and even going so far as to give them names, will allow you to be more specific and contextual when writing user stories. So if you’re going to use user stories, then it’s a great idea to start with user personas.
Wireframes
Wire-framing is an important step in any screen design process. It primarily allows you to define the information hierarchy of your design, making it easier for you to plan the layout according to how you want your user to process the information. Furthermore, wireframes are a great communication tool that sets everyone on the same page, so to speak.
It’s like an architectural blueprint. You need to see it in 2-dimensional black and white diagrams before you understand how to build the actual house. It’s much easier to imagine how a feature will work with a quick sketch than from a paragraph of text. Similarly for a screen design, you can’t start building layers in sketch, or writing blocks of code, without knowing where the information is going to go.
At a deeper level, a wireframe is also very useful in determining how the user interacts with the interface. For example, wireframes may contain various states of button or menu behaviors.
Wire-framing is important because it allows the UX designer to plan the layout and interaction of an interface without being distracted by colors, typeface choices or even copy. If a user cannot figure out where to go on a black and white wireframe, it doesn’t matter what colors you eventually use. A button has to be obvious even if it’s not shiny or brightly colored.
Like the foundation of a building, it has to be fundamentally strong before you decide whether to give it an expensive coat of paint.
User Flow / User Journeys
If a user story helps set expectations for a specific feature requirement, then a user flow provides context for how the user got there and where she ends up after completing the task. Imagine a flow chart showing the different screens/templates/pages/components a user might visit in series on order to achieve their end goal. On this flow chart you can label decision points and what actions the user takes.
Each step is given an ID and each ID can branch off into sub-tasks. The IDs are useful for being able to refer to specific points in the documentation when discussing them with others on the team. This can certainly get messy, which is where a nice diagram can come in handy.
Functional Requirements
The crazy part in learning how to write requirements is how much forethought is required before you really start getting into the requirements.
You may have identified a feature, written user stories for it, and incorporated it into a user flow. Now you need do document the details of exactly how it should work.
You can be as detailed as you need to be, but it’s generally better to write as much detail as possible, while trying not to be too rigidly defined that it stifles creative license during design and development. The goal here is to break the feature down into its smallest testable components that might be directly translated into individual Product Backlog Items (PBIs). Some technical expertise would be required here.
Assumptions
Every decision you make is wrought with assumptions. It’s hard to be aware of everything, but acknowledging anything you might be taking for granted is important because it provides a window into the decision-making process. Documenting assumptions allows others to understand your logic and provides an opportunity to fuel further discussion and identify possible edge cases.
Constraints
A constraint is a limitation that may be outside of your control. Trying to pin these down early helps others on the team plan. It’s also helpful to ask others if they can identify any other constraints, because sometimes you don’t know what you don’t know…
Acceptance Criteria
The final part of feature requirements is documenting acceptance criteria — setting expectations for the whole team about what they must commit to in order to deliver each feature.
Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system. They’re a set of statements, each with a clear pass/fail result, that are focused explicitly on user needs and expectations, and specify both functional and non-functional requirements.
Unfortunately, we often overlook or undervalue acceptance criteria as an aspect of the iterative planning process. Projects succeed or fail based on the ability of the team to meet their customers documented and perceived acceptance criteria! When we clearly define the criteria up front, we avoid surprises at the end of a sprint, or release, and ensure a higher level of customer satisfaction. In other words, we’re able to answer these two important questions: Did we build the right product? And, Did we build the product right?
Acceptance criteria should state intent, not not the solution itself, e.g., “User can approve or reject an invoice” rather than “User can click a checkbox to approve an invoice”. The criteria should be independent of the implementation, and discuss what to expect, and not how to implement the functionality.
In Agile Scrum, you’ll probably hear acceptance criteria referred to as the “Definition of Done”. There is no partial acceptance — something is either done, or it isn’t…
