4.1. Gathering Requirements

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: 

1. Take a system requirement and change it to a user requirement.
   1. First, identify the users in detail and build user personas.
      1. Make a list of user types in detail.
      2. Employ user personas whenever possible.
         1. 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.
         2. Data should back your user personas.
         3. Employ empathy to capture their explicit and implicit goals.
            1. Explicit goals: What they write on their resume, what they talk about, and what they might say in a job interview.
            2. 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. 
      3. “Provider,” is not a user. 
         1. Be descriptive and identify core end-users
            1. Provider Type 1: Nurse Practitioner
               Provider Type 2: Billing Specialist
         2. Identify and manage ancillary stakeholders
            1. User Type: Doctor of Practice 
            2. User Type: Call center customers
   2. Second, convert system requirements to user stories.
      1. Oftentimes, requirements are written in “The system shall…” or “The system must…” They should be changed into as detailed format:

“As a [user]  I need the ability to [user tasks]  so that I can [achieve this goal.] 

1. Example: “The system shall notify the user of changes to status.”
2. 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.” 
3. 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. 
4. 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.
   1. For example: We need to clean up the database.
      1. “Cleaning the database will allow for faster processing of push notifications.”
   2. 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.
5. Third, develop acceptance criteria that are task or action oriented and not use case oriented.
6. Fourth, go through the requirements gathering journey with the developers and testers.