Software requirement analysis
Requirement analysis plays an important role in the software development process. This activity requires very close coordination between customers and analysts to figure out what we have to develop.
1 - Targets and requirements of the software:
Software requirements are all user-specified software requirements including software functionality, software performance, software interface and a number of other requirements. Typically software requirements are classified based on the 4 components of the software as follows:
The most important target of software is to meet the client needs and expectations. Users normally just only give the ideas, they occasionally find ambiguity about the software they want to develop. And the thing a developer needed to do is to make these ambiguous ideas come true and build software with all the necessary features to meet the requirements of the user.
2- The difficulty in analyzing and grasping requirement:
2.1 - User problems:
- Users do not understand what they want.
- Users continuously change their requirement even when the development began.
- Users do not understand technology.
- Users do not understand the development process.
2.2 - Developer problems:
- User and developer’s words do not match.
- The developer tries to drive the user's requirement into an existing system or model instead of developing a system according to customer needs.
- The analysis can be done by the programmers, instead of the analysts so that they can understand customer needs properly.
3 - Requirement analysis phases:
3.1 - Studying software requirements:
- Interview, teamwork, meeting with clients, etc.
- Find experts, user can understand the system needed to be developed to collect various opinions.
3.2 - Analyzing the requirement and negotiating
- Classify software requirements, organize them into related groups based on user requirements.
- Verify each software requirement to determine if they are
- Determine the risk of each requirement.
- Solve the misunderstanding of software requirement by discussion and negotiation.
3.3 - Modeling the requirement:
a - Data Flow Diagram is a technique to present the in-and-out information of a function in the system. The component of the Data Flow Diagram include:
- Functions needed to be processed.
- Data flow.
- Data storage.
- Factor: internal and external factors
b - Entity Relationship Diagram. Entity-Relationship Model is used to design the database in conceptional level. This model is a tool to discuss idea between designer and the end-user in the period of analysis, including three basic components:
- Entity type.
3.4 - Requirement specification:
a - Requirement clarification: requirement is divided into many parts:
- Function requirement: describe specifically a function provided by software
- Non-functional requirement: Constraints on quality, environment, usage standards, software development process.
- Product requirements: Including speed, reliability, memory, interface, operational processes, etc.
- Other requirements: including cost, time, copyright, etc.
b - Requirement specification:
- Non-formal specification: is a specification in natural language.
- Form specification: is a specification in languages of specifications, formulas and charts.
- Functional specification: Normally, when specifying the function of software, the following typical tools are used: Functional Decomposition Diagram (FDD), Data Flow Chart (Data Flow) Diagrams-DFD), Status graph, etc.
- Description specification: The following typical tools are used Entity Relationship Diagrams - ERD, Logic Specifications, Algebraic Specifications.
c - Requirement verification: After the requirements have been built, they need to be verified to whether they meet customer needs. The objective of the verification is to determine if the requirement satisfies the following four factors:
- Does the requirement meet user needs?
- Does the requirement conflict with each other or not?
- Does the requirement include a complete description of all functions and constraints?
- Does the requirement ensure technical, economic and legal aspects?
d - Building the demo:
For complex systems, sometimes we do not know the requirements of the client, we also difficult to evaluate the feasibility and efficiency of the system.
One solution is to build a demo. The demo is both used to analyze requirements and can evolve into a final product. Software demo are not aimed at design verification, but for evaluating user requirements.