Gathering requirements is now, “understanding user needs.” It is the first step of a more user centric SDLC process. At this phase, you can employ design thinking by:
- Take a system requirement and change it to a user requirement.
- First, identify the users in detail and build user personas.
- Make a list of user types in detail.
- Employ user personas whenever possible.
- Document their background, demographics, and biographical information in the greatest amount of detail. They should be based on facts, data, statistics, and observation- not stereotypes.
- Data should back your user personas.
- Employ empathy to capture their explicit and implicit goals.
- Explicit goals: What they write on their resume, what they talk about, and what they might say in a job interview.
- Implicit goals: What they couldn’t say out loud, but may say to their best friend after work. What they are motivated by, naturally, and in an unspoken but understood way.
- “Provider,” is not a user.
- Be descriptive and identify core end-users
- Provider Type 1: Nurse Practitioner
Provider Type 2: Billing Specialist
- Provider Type 1: Nurse Practitioner
- Identify and manage ancillary stakeholders
- User Type: Doctor of Practice
- User Type: Call center customers
- Be descriptive and identify core end-users
- Second, convert system requirements to user stories.
- Oftentimes, requirements are written in “The system shall…” or “The system must…” They should be changed into as detailed format:
- First, identify the users in detail and build user personas.
“As a [user] I need the ability to [user tasks] so that I can [achieve this goal.]
- Example: “The system shall notify the user of changes to status.”
- Into: “As a billing specialist user, I need a UI to alert me when the patient’s status changes from ‘pending’ to ‘approved’ so that I can let the patient know.”
- Translate it into user stories that are as specific as possible. As the requirement gets more defined, change the user stories to match the complexities.
- If it can’t be recorded in the form of a user story, it could mean that it is a technical debt item or a bug fix. Still, they should be told in a way that can demonstrate value to the customer or the business.
- For example: We need to clean up the database.
- “Cleaning the database will allow for faster processing of push notifications.”
- Good Practice: Point these stories like all the other ones, and to keep a separate identifier in the backlog for when the burndown is faster than anticipated.
- For example: We need to clean up the database.
- Third, develop acceptance criteria that are task or action oriented and not use case oriented.
- Fourth, go through the requirements gathering journey with the developers and testers.