Skip to content

Capturing Requirements

Jump to bottom
Jamsheer PP edited this page Mar 2, 2023 · 1 revision

Business/User Requirements

Overview

The very first items that need to be discussed and documented are the business requirements for the project. This is the “why” of the project. These are the fundamental objectives that need to be met to ensure the project has succeeded and are an artifact of discussions between the client and Project Manager (PM). They should be very high level and reflect larger strategic objectives for the client. Also, they should take in account any technical, time, and budgetary constraints that may impact the scope of the project. The size of the project will dictate how lengthy the business requirements will be, but they generally range from a few sentences or bullet points up to a page or two in length. Some brief examples of effective business requirements:

  1. Better communicate our community building efforts to our readers
  2. Reduce the frequency of items being abandoned in carts to increase sales volume

Steps

  1. Conduct a meeting with the business owner to discuss the business requirements
  2. Identify the core non-technical requirements to the project
  3. Identify the following constraints of the project:
  4. Technical
  5. Time
  6. Business owner should provide a Policies and Procedures document documenting all the business logic of the project
  7. Record all requirements shared in the meeting in a document and share it with the business owner for reference

Functional Requirements

Overview

After the business requirements have been gathered, the next step is to explore possible solutions to them and document the result. This is the “what” of the project. Ideating potential solutions should involve team members from as many different disciplines as possible to consider all the alternative approaches to meet the business requirements. This stage could potentially create a crude proof of concept or mockup to verify the solution is viable, but the most important artifact are the rules that dictate how the solution will look and work. Without getting into technical details, determine what needs to happen in order to satisfy the business requirements. These rules should detail the entire workflow including “error paths” that account for invalid data, dependency failures, API outages, etc.

The PM should lead a meeting with representatives of back-end development, front-end development, design/user experience (UX), and quality control (QC) to develop a complete picture of the feature before sprint planning begins. For larger projects, this meeting may need to be repeated as the sprint retrospective cycle provides additional insight. It is vital that the functional requirements are accurate as they become the basis for work estimates and QC test scripts. Functional requirements would look like:

  1. “The events module should automatically display the next 4 upcoming events.”
  2. “An email should automatically be sent to users 4 hours after adding an item to their cart if it has not been subsequently removed or purchased.”

Steps

  1. Conduct a meeting with the development team to discuss the functional requirements
  2. Identify and propose a technical solution for the business requirement
  3. Prepare a mockup or documentation of how the solution’s functionality will satisfy the business requirement
  4. Conduct a meeting with the business owner to share and verify the functional requirements with them

Implementation/Transition Requirements

Overview

Once the functional requirements are complete, the final step is to detail how the solutions will satisfy the functional requirements, and thereby meet the business requirements. This is the “how” of the project. Despite the artifact of these requirements being technical in nature, to avoid later rework it is imperative to consider all aspects of the feature to gain holistic view and develop a complete solution. Be mindful of other features, the site editor experience, dependencies such as APIs and third-party libraries, how back-end and front-end code will be integrated, performance, security, etc. when writing the technical requirements.

Again, the PM should lead meetings with the entire team to review the functional requirements and determine the best technical solutions – potentially prior to each sprint being planned. The feature should be broken down into smaller component tasks that can be completed in one day at this point. Anything larger must be further broken down in order to allow for the most accurate work estimation and burn-down reporting. These requirements will be used as the blueprint for each sprint, so it is vital that they are accurate, complete, and discrete. Based on the previous functional requirement examples, technical requirements would look like:

  1. “Upon successful API retrieval of the JSON object, the event title, date, time, and location placeholders will be dynamically replaced via JavaScript”
  2. “Removing an item from the cart or completing the checkout process will trigger an API call to HubSpot update the user workflow”

Steps

  1. Create an epic (collection of stories) in the project management software (Currently Pivotal Tracker)
  2. For each story, provide the necessary information to complete the story (business value, acceptance criteria, reference documents)
  3. Conduct the Sprint Planning meeting with the Development team
  4. Discuss the epic and the stories it contains
  5. Split stories that are large into smaller stories that can be shippable on their own (if necessary)
  6. Add additional stories (if necessary)

References

Business/User Requirements

  1. What does this project/feature need?
  2. Who is this project/feature for?
  3. Why is this project/feature needed?
  4. What is the input of this project/feature?
  5. What is the output of this project/feature?
  6. What are the technical constraints for this project/feature?
  7. What are the time constraints for this project/feature?
  8. Is there a current implementation or documentation of this project/feature? If so, what is it?

##Capture the Functional Requirements The Business Analyst needs to update the below checklist

  • API Requirement Capture
  • ERP Requirement Capture
  • Issue Capture

###API Requirement Capture

  1. Define the API endpoint, if the requirment is not to update Existing API else mention the existing API endpoint.
  2. Define the mandatory and optional input with input type
  3. Define validations of inputs and the validation messages with status code
  4. Define the success condition, yield and status code with success message and message format
  5. Define the filure condition, yield and status code with error message and message format

###ERP Requirement Capture

  1. Attach the workflow diagram if any
  2. Define if the requirement needs Form/Page/Portal 2.1. Atatch wireframe 2.2. Define no of Form/Page/Portal 2.3. Define each Form 2.4. Define each Page/Portal design and functionalities
  3. Define Scheduled events
  4. Define if the requirement(s) edits the existing form or feature in the core frappe apps

###Define Form

  1. Capture Form Requirements
  2. Define client/server side validations
  3. Define the Actions on after insert/update/submit/save/before save/before submit/cancel/before cancel/trash..etc.
  4. Define filters for the fields in the form
  5. Define workflow for the form

###Define Actions

  1. Define notifcation
  2. Define validation
  3. Define auto defined or auto calculated fields
  4. Condition for the action
  5. Define if the action create/delete/update any record(s) 5.1. Create a record for an existing form, then mention the form(s) 5.2. Create a record for a new form, then define the form(s) 5.3. Mention the codition to fecth the record/field for update/delete

###Define Notification

  1. Define the recipients
  2. Define Mode of notification (Push/System/Email/System-Email/Email-Push/System-Push/All/None)
  3. Define When the notification triggerd (Eg: On Create/Submit/On Workflow/Date and Time)

###Define auto defined or auto calculated fields For example the total in an invoice is an auto calculated field and full name in the employee is an auto defined field from first name and last name

  1. Define the field
  2. Define the conditions and fileds that used for the auto calculation or definition

###Define filters for the fields

  1. Define the field
  2. Define the conditions for the field filter. Same field can have multiple filter based on the condition
  3. Define the filter

###Workflow for the form

  1. Define notification required 1.1. Use Standard notification? 1.1. Define custom notifcation required 1.2. Define the custom format and message
  2. Define the assignees, role and condition
  3. Define the sates
  4. Define the transactions

###Define Scheduled Events

  1. Define the frequency Hourly/Monthly/Daily/Weekly/Cron Time
  2. Define actions

###Define edit existing form/feture from the frappe apps

  1. Define core field changes
  2. Define core action changes(Define Action)
  3. Define method/class overrieds

###Define Core Field Changes

  1. Define the field
  2. Define the field property
  3. Define the field alreday exist in th form or not
  4. Define the condition for update the value/property of the field

###Define method/class overrieds

  1. Define the existing method/class
  2. Define the changes in detail

Form Requirements

DocType Settings

Define the below settings for the DocType:

  1. Name
  2. Module
  3. Is Submittable
  4. Do you want your data to be allowed to be modified after saving?
  5. Is Child Table
  6. Do you want the data in this DocType to be linked in another document as a table?
  7. Is Single
  8. Will this DocType hold multiple records or just 1?
  9. Is Tree
  10. Need more information about this
  11. Quick Entry
  12. Do you need to quickly enter data into this DocType?
  13. Track Changes
  14. Do you want to track any changes that happen on each document?
  15. Track Seen
  16. Do you want to track who has seen/opened the document the first time?
  17. Track Views
  18. Do you want to track who has viewed the documents every time they open it?
  19. Custom
  20. Any Custom DocType will have this checked and cannot be modified
  21. Beta
  22. Do you want the development of the DocType to be in phases and indicate to users that they are not seeing the final version of the DocType?
  23. Is Virtual
  24. Do you want the data to be saved outside of ERPNext? (rare case)

Fields

For each field, determine the following information:

  1. Label
  2. Type (Refer to ERPNext Documentation for list and description of each type)
  3. Name
  4. Length
  5. Used in specific cases to limit the length of the field (e.g. text field)
  6. Mandatory
  7. Is it required for the document to be saved/submitted?
  8. Index
  9. Do you want to optimize searching by this field extensively?
  10. In List View
  11. Do you want this field to be displayed when viewing a list of all documents in this DocType?
  12. In Standard Filter
  13. Do you want this field to be displayed by default when filtering through the documents in this DocType?
  14. In Preview
  15. Do you want this field to be displayed in a quick preview when hovering over it?
  16. Allow in Quick Entry
  17. Should this field appear in the quick entry form?
  18. Bold
  19. Options:
  20. For Links: enter the DocType as range
  21. For Select: enter the list of options, each in a new line
  22. Default
  23. What is the default value for this field if it is left empty?
  24. Fetch from
  25. If the field is linked to another doctype, which field should we fetch the value from?
  26. Should we still fetch if the field from which we are fetching from is empty?
  27. Permissions
  28. Based on what condition should the value be displayed?
  29. Should it be hidden?
  30. Should it be read-only? (Non-modifiable)
  31. Should it be unique? (Not repeated in the DocType)
  32. Should it be set only once? (locked after it is set)
  33. Permission level: by default everything is 0
  34. Ignore user permissions?
  35. Should it be hidden from reports?
  36. Do you want the value of this field to load custom scripts?
  37. Property Depends on
  38. Should this field become mandatory under a specific condition?
  39. Should this field become read-only under a specific condition?
  40. Display
  41. Should this field be filterable?
  42. Do you want to disable copying this field?
  43. Do you want to hide this field from the Print format?
  44. Print width: pixels
  45. Width: pixels
  46. Columns: number
  47. Description: Describe the field

Naming

  1. Autoname: How would you like the documents in the DocType to be named?
  2. Based on a field in the DocType
  3. Using a single naming series (e.g. P000001) that is applied to all
  4. Define multiple naming series (e.g. SO00001 and PO00001) that can be selected
  5. Prompt the user creating the document for a name
  6. Special format (combination of fields and naming series)
  7. Name Case
  8. Title Case
  9. UPPERCASE
  10. Do you want to allow renaming?
  11. Description for the naming logic
  12. Documentation link (if available) to explain how the naming is done

Form Settings

  1. Image Field
  2. Which image field in the doctype should be displayed when viewing the document?
  3. Timeline Field
  4. Do you want a custom timeline other than the one provided by ERPNext?
  5. Max Attachments
  6. Do you want to set a maximum number of attachments the document can have?
  7. Hide Sidebar and Menu
  8. Hide Copy
  9. Do you want to restrict users from copying the form?
  10. Allow Import (via Data Import Tool)
  11. Do you want to import bulk data into the DocType?
  12. Allow events in timeline
  13. Allow Auto Repeat
  14. Do you want to automate creation of documents?

View Settings

  1. Title Field
  2. Which field should appear as the title of the document being viewed?
  3. Search Fields
  4. What fields do you want to search by?
  5. Default Print Format
  6. Default Sort Field
  7. Which field should be used by default to sort the list of documents?
  8. Default Sort Order (Ascending/Descending)
  9. Show In Module Section
  10. Do you want to see the DocType inside the Module section?
  11. Icon
  12. Color
  13. Show Preview Popup
  14. Do you want a preview popup to appear when hovering over a document of this DocType?
  15. Make “name” searchable in Global Search
  16. Do you want to be able to search for your DocType in the Global Search?

Email Settings

  1. Default Email Template
  2. Allow document creation via Email
  3. Do you want to create documents by sending an email to a specific address?

Permission Rules

  1. Do you want to specify permission rules based on roles?
  2. Is the DocType restricted to a specific Domain?
  3. Do you want to restrict searching?
  4. Do you want to restrict creating?

Actions

Do you want specific actions to be performed on the documents? If so, mention them and what they are supposed to do

Linked Documents

Is your document linked to another?

Auto Repeat

Do you want certain documents to automatically be created or perform certain changes on a periodic basis?

Auto Assignment

Do you want documents to be assigned to users/employees based on specific conditions?

Workflow

Does your document need to follow a specific workflow? If so, determine:

  1. Number of steps in the workflow
  2. Actions to be taken in each workflow step
  3. Determining the next-in-line person for each workflow step and how they will be selected

Print Formats

  1. Define what is the print formats needed and the look.

For Mobile App

Use interactive Mockups to show the Use Cases for each function defined in the Business Requirements

Implementation/Ideation Requirements

Follow the Scrum guide to create User stories mentioning the following in the story:

  1. Business Value
  2. Acceptance Criteria
  3. Attachments of references (business requirements, functional requirements, and any additional references)
Clone this wiki locally