This post discusses techniques that can be used to get good requirement documents for softwere projects or applications but it’s likely going to be a similar procedure in other fields of life. Requirement documents are documents that fully state what is required of the application from the users stand point and how the system or the software is supposed to implement or satisfy those functions required. The requirement document helps program designers to understand as much as possible information about the users, the task of the project and the context. It helps the program designer to produce a stable software that is likely satisfactory to users. Failure to understand the requirements of a project can cost designers a lot so it’s a good practice to clearly write your requirement documents to meet thet requirements of the software or application.
The question is how do we get all the information needed to complete a good requirement document for our project? We have to do data gathering and analysis. Simply put, you have to collect data from the users of the system and analyse it to find out what they actually want. This stage of development is very crucial because if for example, a user intended for you to design a software that will keep them awake all night and you build something that will keep them awake all day and sleep all night, you are in trouble. It’s good to clarify things and don’t simply rely on your own judgement about what the users want. Its good to ask and ask till you fully understand the user requirements before proceding to any stage of your software development cycle. There are many ways to get data from the users such as questionnaires, interviews, observations etc. Always remember to choose the best way of collecting data base on what you need. Bad data results in bad conclusions. After data is collected, it has to be analysed. There are various tools to analyse data and it also depend on the type of data you are dealing with. Examples of tools for data analysis are class diagrams, entity-relationship diagrams etc. There are two types of requirements that have to be taken care of in your requirement document: Functional and Non-functional. The functional side is what the system should do to satisfy the user’s need and the Non functional relates to memory size, reponse time of the application etc.
The things that should be considered when studying your requirement are as follows;
Who are the users?
What level of knowlegde do they have about computing?
What environment is the application going to be used?
etc—–
After getting all these information, develop a persona of the user. This means a description of the user based on their requirements and what the software will do. This is not a real person, it’s fake but a representative of the users of the software. You can give them names but remember this is not a real person that you can talk to lol.
Then go ahead and give a scenario about the characteristics of the user and how the user will interact with your program. Doing all these crap will save you time from making mistakes in your final application because it’s easy to spot mistakes at this stage and easily fix it than at the end of the development. You can do use cases to show on paper how your overall application and users are going to interact to complete a task.
For example, if your application is to allow the user to take money from their bank account at an ATM. An example of a used case can be as follows.
(Assume user inserted their card and entered the correct pin.)
1. User clicks on withdraw money.
2. A box showed up asking how much
3. User entered the amount in the box shown
4. A box showed up to confirm the transaction
5. User clicks on “OK” to confirm the transaction
6. System checks if the user have that amount in their account
7. An error message showed up stating user has less money in his/her account than what he/she wanted to withraw and asks if he wants to enter a different amount.
8. User clicks “Yes”
9. Go to step 3,4,5,6
10. If not 7, then System withdraws the amount entered and pushed it out through little window
11. User picked up the cash and smile to the wonderful application
12. User clicks exit
13. Application said “GoodBye” and terminates
This is just a funny use case lol
After doing all these and with better understanding of what you are going to do, you can write a very good requirement document for the project which will help to get the work done right. If you refuse to go through the requirement stage of the project and went straight to writing the software because you think you already know what the users want, you are likely to be revising that project and fixing mistakes and faults forever and ever at the end of it.
