The main reason behind an unsuccessfull project is failures on identifying the requirements. It is difficult to build a solution if you don’t know requirements. What is requirement? Let’s see..
Requirements are the list of what the users need. They are small piece of informations that answers the what the system will do? and how will do that? At this point, requirements are categorized as functional requirements (answers the “what” questions) and non-functional requirements (answers “how” questions).
Functional requirements defines what the system should do. It may be processing, data manipulation or technical details which is the answer of “what” questions such as “What this feature will do?” , “What is the result of doing this ?” etc.
Non-Functional requirements are defines how the system should behave. It is the answer of “how” questions such as “How will the user use this feature?” , “How will the user know the operation is complete?” etc.
Requirement analysis includes of three basic step; gathering, analysing and recording.
Gathering requirements is the first step which includes stakeholders interviews. At this step, requirements are collected from the users, customers and other stakeholders. It is important to finding quality sources of requirements. Stakeholders, Users and subject matter experts, Existing systems and processes and Existing documentations are the examples of source of requirements. There are some requirement gathering techniques such as brainstorming, interviews, observation, questionnaries, use-cases, prototyping. All of this techniques have some advantages and disadvantages.
Sometimes there may be some issues while gathering requirements. Here are some examples;
-Sometimes users do not understand what they want or they do not have a clear idea.
-Users may insist on adding new requirements after the cost and schedule have been fixed.
-Users may do not participate in reviews.
-Users may not understand the development processes.
-Comunication with users may slow.
Also, there are some technical issues can be occur;
-Engineer or developer may start implementation immediately before really understand the whole requirements.
-Engineer or developer may try to make the requirements fit an existing system or model.
-Engineer or developer may not have domain knowledge enough to understand client’s needs properly.
All of these are the points to be careful.
Then, the second step is analysing. Analysing requirements is the process of determining whether the collected requirements are clear, complete, definite and realizable.
After complete analysing requirements, the next step is recording. When the requirements are collected and analysed properly, they should be documented in a form such as use cases, user stories or process specifications.
Gather —-> Analyze —-> Record