As a software developer, every task you do begins with requirement analysis because it affects all phases of your work. If it's not well-done, you will likely make mistakes in later phases. In this article, I’m going to share with you some techniques that can help you be more efficient in analyzing requirements.
Requirement Analysis Procedure
Step 1: Define Software Requirements
You may encounter vague business requirements for software development from time to time. In that case, the first step is to clarify and define them. I'd like to list out several useful techniques to elicit and define requirements as follows:
Document analysis
User manuals and process documents about the current system can become helpful in defining software requirements. Below are a few steps that you can consider for your analysis:
- Collecting relevant documents
- Evaluating these documents if they are appropriate to be studied
- Analyzing them to identify relevant requirements
- Reviewing and confirming identified details
Interview
This technique is very helpful in revealing true software needs. For example, you can make use of questions like who uses the system in what timeframe for what purposes, and how their work.
Observation
Observing can provide further information about processes, inputs, and outputs of the existing system. Sometimes, when you interview stakeholders, they cannot explain enough about their process so consider using this technique to bring out the missing information.
Workshop
Another good method to use is to organize a workshop with a group of users or stakeholders. During the workshop, you can talk with participants to discover, define, scope, and prioritize their needs in a new software system. This technique is very efficient in specifying requirements since it promotes mutual understanding from direct communication between stakeholders and the project team.
Brainstorming
Another practical approach is to determine requirements. Users can come up with very innovative ideas that they have seen or experienced somewhere else. Then, you need to collect all their ideas then review and keep relevant ones to include in the new system.
Prototyping
The prototyping technique is often used to present screen mock-ups to users to get their feedback. This helps them visualize how the system will be so that they can provide very useful comments to help recognize requirements that truly meet their needs.
At the end of this step, you may have a clear understanding of the system and how it should work. You should put in a Word document features and functionalities of the system, as well as any business logic like data validation or calculation. This kind of document is known as the Software Requirements Specification (SRS).
Step 2: Analyze Requirements
Once you have software requirements defined, move on to breaking them down into smaller categories by features and functionalities. The result of this breakdown looks something like this:
- Module 1 / Screen 1
- Feature 1.1
- Function 1.1
- Function 1.2
…
- Feature 1.2
- Function 2.1
- Function 2.2
…
- Feature 1.1
- Module 2 / Screen 2
- Feature 2.1
- Function 1.1
- Function 1.2
…
- Feature 2.2
- Function 2.1
- Function 2.2
…
- Feature 2.1
The software requirements are now divided into chunks that can be documented as user stories. You should use a project management tool like Jira or Trello to document these user stories.
Step 3: Break Down Tasks
To this step, you already have the requirement breakdown structure tree which provides a complete understanding of what requirements to meet. It is time to turn them into actionable tasks that are fine-grained enough to get done. Remember that the coding and verifying tasks are like leaf nodes of the above tree. The final result could be something like this:
Software Requirement Breakdown in Practice
Let's analyze an example of which requirement applies to the above procedure.
Define Requirements
Collect and Understand Requirements
The Agent Portal document is provided by the client over email. While screening it, there are words/terms I’m unsure of: Payment schedule, payoff, reschedule a payment. I will then research to learn about them. In case I’m still unable to figure them out, I will ask my client who is the domain expert.
Define Requirements
Once I collect all requirements (including answers for my questions), I will analyze and codify my understanding and define how the application should work: An agent signs in and the system shows a list of loans. He/she can search by loan number, click to view loan detail info. From the loan detail screen, he/she can schedule a payment, skip a payment, reschedule a payment, schedule a payoff, etc.
Analyze Requirements
What I would do in this step is to read the requirement documents from top to bottom looking for actions that the user would like to take or the system should do (look for verbs or phrases that are associated with the user or system: should be, should show, etc...Any indicator that can help me list out actionable requirement items). The result would be like this:
- Authentication
- Admin to login to manage agents only, not to manage loan payments
- Agent to login to the portal
- Agent to logout
- Agent management
- Admin to create a new agent
- Admin to update an existing agent
- Admin to delete an agent
- Agent to not be able to access and manage other agents
- Loan management
- Agent to search loans by loan number
- Agent to schedule a payment for an existing loan
- Agent to skip a payment for a given loan
- Agent to reschedule a payment
- Agent to schedule a payoff
- System to send an email to the customer when a payment is scheduled
Break Down Tasks
Upon the requirement items identified in step 2, what I would do in this step is to define tasks that need to be done to complete each requirement item. There may be some tasks that are shared among the requirement items so we organize them in separate groups. The result would be like this:
- Create Login UI with email/password fields
- Implement a logging mechanism to log all exceptions
- Authentication
- Admin to login to manage agents only, not to manage loan payments
- Implement Agents list screen showing all agents with add/edit/update buttons
- Implement Admin role for Login API
- Error "Access denied" returned if the account is not registered/invalid
- Access token returned along with role ID if the account is valid and found
- Access denied error shows when navigating to Agent's home screen directly from the browser address bar
- Agent to login to the portal
- Update Login API to support Agent role
- Show agent's home page instead of admin's page upon successful login
- Access denied error shows when navigating to Admin's home screen directly from the browser address bar
- Admin to login to manage agents only, not to manage loan payments
- Agent management
- Admin to create a new agent
- UI for adding a new agent
- Implement Add new agent API
- The error shows if agent email is duplicated
- Notification (success for failure) shows for 3 seconds
- Agents list updated upon successful addition
- Resending activation email should be active if the user doesn’t receive the activation email or forget activation
- Admin to update an existing agent
- Modify Add new agent screen for updating an agent
- Implement Update agent API
- The error shows if the email is duplicated with another agent's email
- Notification (success for failure) shows for 3 seconds
- Admin to delete an agent
- UI for the confirmation message
- Implement Delete agent API
- The error shows and no deletion if that agent has associated data (loans, payments already processed)
- Notification should be in red color
- Agents list updated upon successful deletion
- Admin to create a new agent
- Loan management
- Agent to search loans by loan number
- UI for agent's home page (list of loans)
- API for searching for loans by number
- The loan number must not be null
- Access is denied if an invalid access token is passed in.
- Front-end code to call API and show loans
- Agent to search loans by loan number
- Agent to schedule a payment for an existing loan
- UI for scheduling a payment
- API scheduling a payment
- A payment schedule must not be created for loans that already have a schedule.
- Error from ABC must be returned to the client without exposing sensitive info, and log
- Front-end code to consume API
- Payment schedule info refreshed when successfully scheduled
- Agent to skip a payment for a given loan
- UI to confirm skipping a payment that is due
- API to skip a payment
- The amount of the next payment must be accumulated for this skipped one
- Front-end code to consume API
From there on, we can break down task items and unit test cases the same way.
- Agent to reschedule a payment
- Agent to schedule a payoff
- System to send an email to the customer when a payment is scheduled
- Agent to logout
Appendix
Below is an example of a requirement document ready for analysis:
Our client is a leasing agency that is using a loan management system called X which exposes API for developers to use to interact with their system from third-party software. The demand is to create a web application that would enable an agent to schedule a payment, change payment method or schedule a payoff for a customer at a date in the future using the API that the X loan system exposed.
Functional Requirements
- Admin to manage agents (add, remove)
- Agent to log into our web application to do work
- Agent to search for a loan using the loan number
- Agent to schedule a payment for a loan in the future
- Agent to skip a payment for a loan
- Agent to reschedule a payment
- Agent to schedule a loan payoff
- System to send out an email based on the email template whenever a payment is scheduled to the customer
Technical Requirements
The ABC’s API documentation is at https://api.xxx.com/help/index. The client proxies the call through our API instead of interacting with it directly from the front end. The API code is at https://github.com/xxx and ABC’s API documentation explains how it would work. The following endpoints are in particular interest:
- POST /api/v1/loans/{loanId}/payoff (to schedule a payoff)
- POST /api/v1/loans/{loanId}/payments (to schedule a payment)
- PUT /api/v1/loans/{loanId}/payments/{paymentId}/dueDate (to reschedule a payment)
- PUT /api/v1/loans/{loanId}/payments/{paymentId}/paymentMode (to skip a payment, change paymentMode to Cash (id =7))
Their API does not have every ABC’s API proxied so we will need to fill in all the missing ones.
The client is going to either reuse the meridian/crystal front-end or create something new, whichever is easier for us. We can use Syncfusion UI controls or material controls, again whichever is easier.
To test, we can use the username/password for clientCode “abc”, which is also the default client, and we don’t have to send in the client code param to interact with the ABC system. The client advised us to look at ABCApiExt.cs class in the Meridian.Web.Api project.
The test customerId is abc and the test loaned is xyz. We are also advised to be careful and use only this loan as it is associated with the production system.
