Recently I completed a project that was challenging in the best of ways. We were asked to study and understand the client’s current system to write their next system requirements. The client asked us to glean system requirements from reviewing the system, speaking with users, and combing through as much documentation as possible.

The task felt monumental – we needed to understand the system as it was, but with an eye for improving the new system. Documentation was sparse. The system contained three sub-systems, managed and used by individuals at several locations across the country. Many end-users were experts, having learned a system that was not too user friendly; they often relied on their historical knowledge and experience to accomplish their tasks. Also, outside tools such as chats, emails, excel sheets, and other applications were often leveraged due to dated and incomplete functionality.

This was not my first time trying to take a big set of somewhat nebulous ideas and translate them into functional system requirements. The process is a bit of an art, and nothing can replace experience with this kind of task, but these repeatable processes will help you take conversations and create requirements. If you have been tasked to manage or participate in a study to develop requirements, these steps could help you succeed.

1. Have the right team in place

It would be best to have innovators on your team that can take a big-picture problem and break it down into bite-sized, usable pieces. It isn’t easy to look at a resume and figure out a mind-set like this. When putting together your team, have a gifted project manager or technical lead that can distribute tasks that optimize individual strengths.

Consider including an experienced tester that can guide completeness and understanding of requirements and who will enjoy clicking through the entire system and documenting the functionality. Include system engineers and architects who can quickly understand the current system and assess what is required to meet functionality versus technical limitations. Include a user experience researcher to develop questionnaires and interact with users.

Be careful not to choose only individuals with a lot of experience with the current system. This can often bias your results and limit your team’s ability to explore and learn.

Assign sections of work to different teammates. System architects should be concentrating on writing requirements for system dependencies, input/output requirements, existing architecture, and potential improvements to the design. Security information specialists can assist with documenting any guidance, laws, or conditions that must be considered in the design and system requirements to meet said requirements. Software engineers can concentrate on frameworks, limitations, and expectations that the software will need to accomplish. User experience personnel should focus on user functions. Know what the system will be and bring in the experts to help. For example, our client considered automation, machine learning, and cloud architecture as part of their solution. Including individuals who were excited to research these items and experience where to start was critical to the work.

2. Be as selective as possible with who interacts with the end-users on the team

Ideally, you will have user experience specialists leading the charge of any interactions with users. Their focus is to understand the user through observations, focus groups, and questionnaires. There are essential, subtle practices that a user experience specialist invokes to ensure quality data is gathered while interacting with the users. Other teammates can join in on observations and discussions, but their primary task should be to learn and take notes.

Alternatively, if you know you will be meeting with a specific audience (for example, the database administrators of the current system), bring a teammate that has experience with the technology being discussed.

3. Learn as much about the system as you can prior to user interactions

I have found the best place to start is training material and help documentation. To understand the functions of the system as a user, you must try and become the user. Explore the course if you can on your own time before meeting with users. Click every button, explore every menu. Write observations about interactions, patterns in design, and lingo.

4. Optimize user interactions

Ask for a representative user group. When talking with your stakeholders, project management, or clients, ask for a diverse user group. I specifically like to ask for users ranging from very experienced to junior. Users that are resistant to change or are frustrated with the current system. It is ideal to have contacts for 3-5 users for each system role, if possible.

Meet one on one with users and ask to observe. This is one of the biggest challenges I run into. Managers of the project have the best intentions, so they will often ask to have just a big group meeting so “everyone can be heard.” Still, presentations and discussions often lead to a disjointed and incomplete view of the system. Ask if you can sit with your users to observe how they use the system. It is okay to ask to repeat an observation more than once as your understanding of the system increases?

Assume nothing, ask the obvious, and seek understanding. Even if you think you know an answer, ask the obvious questions when working with the users. It is essential to hear from the user how they will accomplish a task, where they have issues with the system, or how they work around the design issues. I often see individuals who are not experienced in user observation want to jump in and show their understanding. Being quick to demonstrate your knowledge may shut your users down or have them skip essential steps in their tasks.

Ask pointed questions but be flexible. It’s great to have a planned list of items but be adaptable with any user interactions. Show the user you are hearing them by making sure the questions make sense and add to the conversation context. Just running through a list of items can turn off by boring the users or making them feel you must only “check the box.” Specifically, I like to ask the following:

• What are the critical functions that we must ensure the system has? If a system exists, follow-up by asking them to show you how they accomplish those critical functions.
• What would you say your role is regarding this system?
• What tasks are you responsible for? Can you show me how you accomplish these?
• Who do you interact with to accomplish the tasks?
• What about the system causes problems? If possible, focus on the system, not the users. You will still often be able to tease out problems and errors that the users make through these questions.
• If you were training me, what you want me to make sure I understood?
• What would you like to improve the current system?

Parrot back what you think the user has said. This is important for two reasons:

1. It shows the user you are listening and invested in their feedback and knowledge and
   It gives an opportunity to correct misunderstanding.
2. Avoid getting into implementations and solutions with your users. It is human nature to want to jump to “just add a button that lets me do X, Y, Z.” Though it is fine for a user to give this type of feedback, focus on the need, not the implementation during these discussions.

5. After your meeting with the users, immediately start organizing your notes

I need time to write things down and organize them on my own. I will often write the same set of notes twice- once in order of the conversation, and a second time by grouping information under functionality or tasks.

You can work with your team during this time to consider
Card sorting exercises are often leveraged in designing the organization of a system. Write down as many functions as you know the system must have, and then group them. Allow everyone on the team to participate to see what trends arise and discuss where the team disagrees. At first, try and group items. You can decide on the hierarchy later. Questions that will help you group information for requirements writing:

1. What must the users create, complete, pass along, edit, share?
2. What permissions are necessary to protect, create, and manage data in the system?
3. Does the client want you to consider off-the-shelf products? If so, do you inherit specific behavior or limitations based on this choice?
4. What are the critical tasks for the system?

6. Create parent functions

With this client, there were a lot of details from multiple meetings, observations, and documents. It was essential to create high-level “parent” functions (for example: Create a product) and then link the parent function to all the supporting needs. The parent functions are called different things depending on your goal; these may be key performance parameters, functional requirements, capability statements, or system functions.

Create flow diagrams, user personas, use cases, and prototypes. These are great tools to figure out if you understand something from beginning to end. Each has its pros/cons. My personal favorites are use cases and prototypes.

7. Identify research tasks

I have yet to get every piece of information I need in the first round of document reviews and user interviews. By creating diagrams and grouping requirements together, you will start to see where your data is weak. If your team is large enough to support the effort, break up tasks by expertise. Trade-off tasks and documentation so that there is a fresh set of eyes looking at existing information to find what you are missing. Realize that with each pass-through, your understanding will increase, so it is worth revisiting information.

8. Write, review, and revise

Review your work with the appropriate users. Once you have a basic idea of the system’s critical functions, ask to meet back with the users. Ideally, this interaction would be led by the user experience expert on your team. The goal will be to ensure understanding, so welcome critical feedback. When users see things like a flow diagram or a use case, they will often remember something initially left out. This is an excellent way to ensure every function is understood and documented.

Enter the writing portion of your requirements with an open mind. We wrote and rewrote requirements with our project, changed the groupings of parent/children, and added sub-sections multiple times.

Write S.M.A.R.T. Shall Statements. Specific, measurable, attainable/achievable, realistic, timely requirements. Once you have a good idea of what the requirements should be, write to them to be as transparent as possible. Your tester can be a tremendous asset to the team. Ask them to review the requirements and let you know if they could write a test script off the requirement. Let them help you determine where there is ambiguity.
For each critical piece of information, you will write one requirement in the form of a “shall” requirement. For example, “The system shall allow users to withdraw money from accounts they have the appropriate permissions to access” Write all desired behavior in the form of a “will” statement. For example, “The system will include audio signals for successful withdraw of money.”

If writing functional requirements, avoid system-specific lingo. Focus on what the user must accomplish and how. Avoiding lingo, existing system labels, and flow of how the user will complete a task end-to-end are especially essential when you are building and improving upon a current system.
For example, we wanted to avoid the use of role names in the requirements with our client, so we stated things like “user with the appropriate permissions” instead of “product manager.” You can capture the need without limiting the new system in roles that may be unwarranted.

Include prototypes, user personas, experience flows, etc. as part of the final document to understand requirements. This is especially important when you are suggesting improvements or new ideas for the next system.
It is difficult to translate complex ideas between people, and the old saying of “A picture is worth a thousand words” holds in this case also.

9. Present the information to stakeholders as part of the project wrap-up

If possible, don’t just hand over the completed requirements document and walk away. Our requirements document was well over 100 pages and full of important information critical to our customer’s next system. Consider walking through the document with your stakeholders as a final step. Point out areas that may need more consideration and design. Ensure understanding the point of all parent requirements and the philosophy behind the requirements’ grouping and organization.

Having the task of creating or updating requirements can be a daunting process. It can be incredibly difficult to take many conversations and determine how to translate those into written, concise requirements.

I am excited when the client allows me to influence the requirements. I hope that by sharing my insights that you will gain confidence in taking conversations to needs. By following these suggestions and guidelines, you will regularly engage with your users, optimize your team’s time by focusing on their area of expertise, and deliver feature-complete, intuitive projects to your clients.