1. The importance of needs analysis
Software requirements refer to the user's expectations of the target software system in terms of function, behavior, performance, design constraints, etc.
Generally, the software life cycle includes activities such as feasibility analysis and development item planning, requirements analysis , design ( outline design and detailed design ), coding, testing, and maintenance .
Among the three commonly used software life cycles (waterfall model, iterative model and rapid prototyping model ), requirements analysis plays a pivotal role and is the input of system analysis, software programming, software testing and system maintenance.
Five important steps in the software life cycle: need, analyze, page, design, develop.
1.1 Waterfall Model
The waterfall model is famous for its resemblance to a waterfall, and the (Waterfall Model) was first proposed by Royce. In this model, requirements are first identified and validated by the customer and the SQA team. Then the specification is drawn up, and after the verification is also passed, the planning stage is entered... It can be seen that the crucial point in the waterfall model is that only when the documentation of one stage has been prepared and approved by the SQA team, the next stage can be entered. In this way, the waterfall model ensures that each stage can complete the task well by mandatory requirements to provide specification documents. But it is often difficult to do in practice, because the entire model is almost document-driven, which is difficult for non-professional users to read and understand.
As can be seen from the above figure, the output of requirements analysis, "Requirements Specification" (some project teams also produce software prototypes , such as static HTML prototypes, etc.) is the basis for subsequent design, coding, testing and system maintenance.
Software prototyping is an important part of requirements analysis.
The "requirements analysis" phase of the waterfall model can be subdivided into two phases: "software concept" and "user requirement analysis". The former is used to collect the original requirements of users, including users' requirements in terms of functions, behaviors, performance, and design constraints. Expectations , and after preliminary analysis, the "User Requirements Specification" is formed, and then after further analysis, the user requirements are refined and complete, and finally the "Requirements Specification" is formed.
The "system design" in the waterfall model can be subdivided into two stages: "architecture design" and "detailed design". The former is generally grasped and focuses more on the architecture level, including the overall architecture of the system, as well as individual subsystems or individual modules. The relationship between. The latter pays more attention to details, including all aspects of system design, which should be reflected in the detailed design.
As a system analyst or system architect, he mainly reflects his role in the stages of "requirements analysis" and "system design", and implements his own design through communication with project team members in subsequent stages.
1.2 Iterative Model
The iterative model is the cycle model recommended by RUP (Rational Unified Process, unified software development process , unified software process ) . In RUP, an iteration is defined as one that includes all development activities leading to a product release (a stable, executable version of the product) and all other peripheral elements necessary to use the release.
In a way, a development iteration is a complete process of going through all the workflows: (at least) requirements workflow, analysis design workflow, implementation workflow (coding process), and testing workflow. Essentially, think of it as multiple small waterfall projects. Each iteration produces a release-ready product that is a subset of the final product.
The iterative prototype diagram is as follows:
In each iteration, the "Requirements Analysis" phase, like the waterfall model, is the basis upon which subsequent system analysis, coding, and testing phases depend. If there is a large deviation in the requirements analysis, it will inevitably cause a large deviation in a product subset generated in the iterative process.
1.3 Rapid Prototyping Model
The Rapid Prototype model is functionally equivalent to a subset of the product. Note that this is functional. The disadvantage of the waterfall model is that it is not intuitive, and the rapid prototyping method solves this problem. Generally speaking, according to the needs of customers, the most urgent needs of users are solved in a very short period of time, and a product that can be demonstrated is completed.
After getting the user's needs, the prototype will be discarded. Because of the rapid pace of prototyping, the design aspect is hardly considered, and if the prototype is retained, it will pay a huge price in subsequent development.
In the rapid prototyping model, the most important purpose of the prototype is to determine the real needs of the user. To a certain extent, rapid prototyping can be understood as a more intuitive way of requirements analysis, and it is also a way that the industry recognizes and achieves good results.
2. The goal of needs analysis
Through the understanding and analysis of the corresponding problem and its environment, a model is established for the information, functions and system behavior involved in the problem, the user requirements are refined and complete, and the requirements specification is finally formed. This series of activities constitutes the software development life cycle requirements analysis stage.
Requirements analysis is the bridge between the system analysis and software design phases. On the one hand, requirements analysis takes system specification and project planning as the basic starting point of analysis activities, and checks and adjusts them from the perspective of software; on the other hand, requirements specification is the main basis for software design, implementation, testing and maintenance. . Good analysis activities help to avoid or eliminate early errors early, thereby increasing software productivity, reducing development costs, and improving software quality.
3. How to conduct demand analysis
3.1 Difficulties in Requirements Analysis
The goal of requirements analysis, to put it more simply, is to determine "what to do and what not to do". But demand analysis is not as simple as imagined, mainly because of the following reasons:
3.1.1 Customer demand itself often changes
In everything in this world, only "change" is absolute. From this point of view, it is understandable that the requirements of software systems are constantly changing. Designers and developers often complain that customer needs are always changing. In fact, "changes in requirements" should be understood as a normal state.
There are many reasons for changes in demand, such as:
(1) Because some preconditions were not met, it was implemented according to the "compromise" scheme before, but if these preconditions are met at a certain point in time, it will cause a change in demand.
(2) There is no need to go through the approval process before a background operation, but because a certain internal process of the customer needs to go through the approval process, it will inevitably lead to a series of changes in requirements->design->coding->testing.
[Countermeasures] : Because demand changes are inevitable, system analysts need to be clear when conducting demand analysis:
(1) Analyze as much as possible which are stable requirements and which are volatile requirements. In order to carry out system design, the core of the software is built on stable requirements, otherwise it will suffer.
(2) Be sure to clearly state "what to do" and "what not to do" in the contract. If the contract is vague, there will be more disputes in the future. Small changes have little impact and will not affect the progress, but the need for some changes to cause major changes to the design needs to be clearly stated in the contract.
3.1.2 The customer cannot explain the requirements clearly, and the analyst misunderstands
Customers' computer level, understanding of needs, and degree of expression are all uneven. Some customers have only a hazy feeling about their needs, and of course they can't tell the specific needs. Some clients know exactly what they want, but can't articulate it. Some customers themselves understand software development and can articulate their requirements clearly. Such requirements analysis will be very easy and enjoyable.
System analysts with different personalities, different levels, and different preparations before communicating with customers will get very different results when discussing requirements with customers.
As a system analyst, you can guide the customer, first explain the conventional requirements, and then the customer rejects the unneeded, and finally determines the customer's real needs. A good system analyst can put forward a lot of his own opinions from one or two sentences of the customer or can expand, and then further explore customer needs, or if it contradicts the previous needs, he can conduct correct demand orientation.
[Countermeasure]: If the customer does not know the requirements clearly, in order not to cause misunderstanding, the system analyst can use multiple communication methods, such as the first time through the customer to get a preliminary understanding of the requirements, and then go back to analyze which are reasonable requirements and which are self-contradictory. or unreasonable needs, and which needs to be further clarified. After refinement, the second communication can provide PPT or simple Word document for second in-depth communication with customers. The third exchange can further communicate with customers to obtain precise requirements by building a quick model. Requirement analysis can also refer to the "iterative model" for continuous iteration until all the potential needs of customers are discovered.
3.1.3 When the customer does not see the prototype or the complete system, there are some potential needs that have not been tapped
There are even a lot of such customers, who can't put forward too many requirements when communicating their requirements, but when you complete the whole system, potential requirements suddenly burst out.
[Countermeasures]: In order to avoid the destructive impact of this situation on the project, it is recommended that relevant personnel establish rapid prototypes for some large functional modules for the customer to confirm, and must clearly state "what to do" and "what not to do" in the contract "
3.1.4 The requirements of multiple stakeholders conflict with each other, and the requirements are ambiguous
If some requirements involve different departments of the customer, if there is disagreement, if you modify it privately according to the opinions of one party, it is likely to involve the transformation according to the ideas of another department in the later stage.
[Countermeasures]: For such conflicting needs within the customer, organize the relevant departments of the customer to discuss the needs, and the higher leadership of the customer decides which party needs to be realized, or a compromise solution is adopted. Requirements specification must not be ambiguous, let alone contradictory. If there is ambiguity or inconsistency, reanalyze the requirement.
3.2 Activities of needs analysis
3.2.1 Demand acquisition
Develop, capture, and revise user requirements by interacting with users, observing existing systems, and analyzing tasks .
The common acquisition methods of software requirements ( written in detail in the article " Software Requirements Acquisition Methods ") are as follows:
ØInterview _
Personally, I think interview is the most useful method to obtain software requirements, and it is also a commonly used method in requirements analysis. Through various interviews, we have obtained the most information. We have carried out the system we are doing now, and conducted interviews with the customer department, business support department, network management center, and system operation personnel of the Mobile Group.
What to prepare for the interview: the interviewee and the interview questions.
Interview objects: It is necessary to try to make the interview objects include stakeholders who can be related to the system and be representative to ensure that each role is covered. Generally including who pays for the system, buys the system? Who uses the system? Who will be affected by the results of the system? Who will oversee the system? Who will maintain the system?
Ø Questionnaire survey
Questionnaires cannot replace the role of interviews in the stage of demand acquisition. The questions and answers of the questionnaires are instructive to some extent, which will affect the results to some extent.
The quality of the results of the questionnaire is directly related to the design of the questionnaire. During this project, the operators also sent questionnaires to corporate customers during the pre-promotion meeting, but for many reasons, the effect was not ideal. Didn't do much analysis for our project requirements.
o Group discussion
A group discussion is a meeting where people related to a project issue come together to discuss. Advantages: It is easy to obtain the approval of the plan internally, which is conducive to the development of the project; at the discussion meeting, each relevant person can express their own opinions, which ensures the comprehensiveness of the information obtained. Disadvantage: not easy to grasp.
For requirements involving system boundaries, or some conflicting requirements, this approach is highly desirable.
Ø Scenario series
Due to the abstract nature of software products, most stakeholders do not have a clear product outline in their minds, which affects their understanding of the product. Based on this, consider writing a clear and complete scenario description document.
1. Use PPT and pictures to describe the situation: a good PPT can describe various situations more intuitively;
2 , using the prototype method (more recommended this method).
Ø Participate in and observe business processes
涉众描述的业务流程可能由于某些原因会遗漏掉重要的信息，需求分析人员可申请参与到他们具体的工作，观察、体验业务操作过程。需求分析员在观察业务操作过程时，可根据实际的情况提问并详细记录，记录业务操作员操作过程，操作过程中碰到的难题，可获取真实的材料和理解整个业务。
Ø 现有产品和竞争对手的描述文档
阅读现有产品文档有利于了解当前系统情况，从中也可以了解业务流程，对操作员反映的系统问题有着更深层次的理解。
3.2.2 需求建模
要有效地收集需求，您要做的第一步是建模，它包括创建体系结构的表示形式以捕获需求、就解决方案方法进行交流、以及分析所提出的系统设计。其目的是使用模型来表现系统中的关键方面。然后，您可以在形式化的分析、模拟和原型设计中使用这些模型，以研究预期的系统行为，并且可以在编写文档或总结时使用这些模型，以便就系统的性能和外观进行交流。
Ø 域建模
域建模指的是，您对问题域创建相应的模型并且把它划分为若干个内聚组的过程。然后，您可以在抽象模型中捕获业务流程、规则和数据。
域模型是一种用于理解问题域的工具。您需要从信息系统之外的角度来理解这个域，这一点是很重要的。
Ø 用例建模
用例模型描述了各种参与者（人和其他系统）和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。
用例模型应该将系统放到上下文环境中，显示系统和外部参与者之间的边界，并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者（例如，用户和维护人员）所看到的系统行为。
Ø 组件和服务建模
组件模型为子系统、模块和组件的层次结构分配需求和职责。每个元素作为一个自包含的单元，以用于开发、部署和执行的目的。组件模型的元素由它们所提供和使用的接口来进行规定。在这里，没有考虑其中的内部细节。
服务模型将应用程序定义为一组位于外部边界（用例）、架构层之间的抽象服务接口，并且提供了通用的应用程序和基础结构（安全、日志记录、配置等等）。支持应用程序需求的这组服务可以与现有的内部和外部提供的接口规范相匹配。所得到的分析结果可以确定预置策略，并将项目活动划分为特定类型的部分，这取决于给定的服务是否已经存在（内部或者外部的，并且其中每个服务都具有适当的活动）、存在但需要进行修改（定义一个新的接口，并规划其实现）、或者必须构建新的服务。
Ø 性能建模
可以通过各种各样的方式来度量性能，最显而易见的方式是，应用程序执行其关键操作任务的速度。然而，作为一名架构师，必须考虑性能建模过程中其他的几个方面：
l 构建和部署应用程序的速度如何？
l 构建、维护和运行需要多少花费？
l 该应用程序能在多大程度上满足其需求？
l 对于必须使用该应用程序的人来说，需要为其付出多大的开销？
l 该应用程序会对其他应用程序和基础结构产生怎样的影响？
【说明】需求建模是一门深奥的学问，在做这个项目时，需求建模基本只是用到了“用例建模”，对一些典型流程进行用例建模。域建模、组件和服务建模和性能建模基本是空白状态，希望在下一个项目中有所改进。
3.2.3 形成《需求规格说明书》
生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。
3.2.4 需求验证
以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性。
3.2.5 需求管理
持系统的需求演进，如需求变化和可跟踪性问题。
要在需求变更时，同步更新《需求规格说明书》以及相关文档，要知道，一个正确的文档是指导软件系统不同阶段的参考，但一个没有同步更新的文档是对软件系统有破坏性作用的，相关人员会受到错误引导。