📚 System Requirements Definition and Investigation Analysis | 系统需求定义与调查分析
The foundation of any successful software project lies in a clear and unambiguous definition of system requirements. Before a single line of code is written, analysts must identify what the system is expected to do, how it should behave, and under what constraints it must operate. This process—known as requirements definition and investigation—is the first critical phase of the Systems Development Life Cycle (SDLC).
任何成功的软件项目都建立在清晰且无歧义的系统需求定义之上。在编写第一行代码之前，分析师必须确定系统预期要做什么、应该如何表现，以及在哪些约束条件下运行。这一过程——称为需求定义与调查分析——是系统开发生命周期（SDLC）中第一个关键阶段。
1. What Is a System Requirement? | 什么是系统需求？
A system requirement is a precise statement describing a specific capability, feature, or constraint that a system must satisfy. Requirements serve as the contract between clients and developers, guiding design, implementation, testing, and final acceptance. Without well-documented requirements, projects risk scope creep, budget overruns, and delivery of a product that does not meet user needs.
系统需求是描述系统必须满足的特定能力、功能或约束的精确陈述。需求是客户与开发人员之间的契约，指导设计、实现、测试和最终验收。如果没有文档化的需求，项目将面临范围蔓延、预算超支以及交付不符合用户需求的产品等风险。
In the CIE A-Level Computer Science syllabus, requirements are broadly classified into two main categories: functional requirements and non-functional requirements. Understanding the distinction between these two types is essential for producing a comprehensive requirements specification.
在CIE A-Level计算机科学大纲中，需求被广泛分为两大类：功能需求和非功能需求。理解这两类需求之间的区别对于编制完整的需求规格说明至关重要。
2. Functional Requirements | 功能需求
Functional requirements describe what the system must do—the specific functions, processes, and operations that the system must perform. They are expressed as inputs, outputs, and behaviours. For example, ‘the system must calculate a student’s average grade from their examination scores’ or ‘the system must generate a monthly sales report in PDF format’ are functional requirements.
功能需求描述系统必须做什么——系统必须执行的特定功能、过程和操作。它们以输入、输出和行为来表达。例如，“系统必须根据学生的考试成绩计算平均分数”或“系统必须生成PDF格式的月度销售报告”就是功能需求。
Each functional requirement should be testable. If a tester cannot verify that the requirement has been met, then the requirement is not well defined. Functional requirements often include specific data processing rules, validation criteria, and user interaction flows. They answer the key question: ‘What does the system need to accomplish?’
每项功能需求都应该是可测试的。如果测试人员无法验证该需求是否已满足，则该需求的定义就不够完善。功能需求通常包含特定的数据处理规则、验证标准和用户交互流程。它们回答了一个关键问题：“系统需要完成什么？”
Examples of functional requirements in a library system might include:
图书馆系统中的功能需求示例如下：
- The system must allow registered users to borrow and return books. 系统必须允许注册用户借书和还书。
- The system must send overdue notices to users via email. 系统必须通过电子邮件向用户发送逾期通知。
- The system must track the availability status of each book in real time. 系统必须实时跟踪每本书的可借状态。
- The system must produce a list of books that are due for return on a given date. 系统必须生成指定日期应归还的图书清单。
3. Non-Functional Requirements | 非功能需求
Non-functional requirements specify the quality attributes, performance criteria, and constraints under which the system must operate. They are not about ‘what’ the system does, but ‘how well’ it does it. Common categories include performance, security, usability, reliability, maintainability, and portability. For instance, ‘the system must respond within two seconds under normal load’ or ‘the system must prevent unauthorised access to customer data’ are non-functional requirements.
非功能需求规定了系统运行的质量属性、性能标准和约束条件。它们与系统“做什么”无关，而关乎“做得有多好”。常见的类别包括性能、安全性、可用性、可靠性、可维护性和可移植性。例如，“系统在正常负载下必须在两秒内响应”或“系统必须防止未经授权访问客户数据”就属于非功能需求。
Non-functional requirements are often overlooked by novice analysts because they are less tangible than functional ones. However, they have a profound impact on user satisfaction and system architecture. A system that functions correctly but is painfully slow or difficult to use will ultimately fail in the market. In the examination context, you must be able to give concrete, measurable non-functional requirements rather than vague statements such as ‘the system should be fast’.
非功能需求常常被初学者分析师忽视，因为与功能需求相比它们不太具体。然而，它们对用户满意度和系统架构有着深远的影响。一个功能正确但速度极慢或难以使用的系统最终会在市场中失败。在考试背景下，你应能够给出具体、可衡量的非功能需求，而不是诸如“系统应该快”之类的模糊陈述。
Typical non-functional requirements include performance (response time, throughput), security (encryption, authentication), availability (uptime percentage), and capacity (number of concurrent users). The table below summarizes common categories with examples.
典型的非功能需求包括性能（响应时间、吞吐量）、安全性（加密、身份验证）、可用性（正常运行时间百分比）和容量（并发用户数）。下表总结了常见类别及其示例。
| Category 类别 | Example 示例 |
| Performance 性能 | The system must process 1,000 transactions per second. 系统必须每秒处理1,000笔交易。 |
| Security 安全性 | All passwords must be stored using AES-256 encryption. 所有密码必须使用AES-256加密存储。 |
| Usability 可用性 | A new user must be able to complete a transaction within 10 minutes of training. 新用户经过10分钟培训后必须能够完成交易。 |
| Reliability 可靠性 | The system must have 99.9% uptime each month. 系统每月正常运行时间必须达到99.9%。 |
| Portability 可移植性 | The system must run on Windows, macOS, and Linux platforms. 系统必须能在Windows、macOS和Linux平台上运行。 |
4. The Investigation Phase | 调查阶段
Investigation is the process of gathering information from stakeholders about the current system and the requirements for the new system. It is the primary method by which analysts discover both functional and non-functional requirements. A thorough investigation involves multiple techniques, each with its own strengths and weaknesses. Selecting the appropriate technique depends on factors such as the number of stakeholders, the availability of documentation, and the complexity of the existing system.
调查是从利益相关者那里收集有关现有系统和新系统需求信息的过程。它是分析师发现功能需求和非功能需求的主要方法。全面的调查涉及多种技术，每种技术都有其优缺点。选择合适的技术取决于利益相关者的数量、现有文档的可用性以及现有系统的复杂性等因素。
CIE examinations frequently ask candidates to evaluate these techniques. Therefore, memorising a list of methods is insufficient; you must understand when and why each method should be used, and be prepared to compare their relative effectiveness in a given scenario.
CIE考试经常要求考生对这些技术进行评估。因此，仅仅背诵方法列表是不够的；你必须理解何时以及为何使用每种方法，并准备好在给定情境下比较它们的相对效力。
5. Interview Technique | 访谈法
Interviews involve one-to-one or small-group discussions between the analyst and stakeholders. They are perhaps the most flexible information-gathering technique because the analyst can adapt questions in real time based on the respondent’s answers. Open-ended questions encourage detailed responses, while closed questions (yes/no or multiple choice) provide quick, structured information. Interviews can be conducted with users, managers, and technical staff to capture different perspectives.
访谈是分析师与利益相关者之间进行的一对一或小组讨论。它们可能是最灵活的信息收集技术，因为分析师可以根据受访者的回答实时调整问题。开放式问题鼓励详细回答，而封闭式问题（是/否或选择题）提供快速、结构化的信息。访谈可以与用户、经理和技术人员进行，以获取不同视角的意见。
One of the main advantages of interviews is the depth of information they can reveal. An experienced interviewer can probe beyond surface-level answers, detecting underlying concerns, conflicts, and unexpressed requirements. However, interviews are time-consuming and expensive, especially when many stakeholders are involved. The analyst’s skill also affects the quality of the results; a poorly conducted interview may miss critical issues or bias the respondent’s answers.
访谈的主要优势之一是它们能揭示信息的深度。经验丰富的访谈者可以深入追问表面答案之下的内容，发现潜在的问题、冲突和未表达的需求。然而，访谈耗时且昂贵，特别是当涉及许多利益相关者时。分析师的技巧也会影响结果的质量；进行不当的访谈可能会遗漏关键问题或使受访者的回答产生偏差。
6. Questionnaire Technique | 问卷调查法
Questionnaires are printed or electronic forms containing a set of predetermined questions distributed to a large number of people. They are an efficient way to collect data from many respondents across different geographic locations. Questionnaires typically include a mix of multiple-choice, rating-scale, and free-text questions. They are particularly useful for gathering opinions, preferences, and routine information from a broad user base.
问卷是包含一组预设计问题的印刷或电子表格，分发给大量人群。它们是从不同地理位置的多位受访者处收集数据的有效方式。问卷通常包含选择题、评分量表和自由文本问题的组合。它们特别适用于从广泛的用户群体中收集意见、偏好和日常信息。
The strengths of questionnaires include their low cost per respondent, anonymity (which may encourage honest feedback), and the ease of statistical analysis of responses. On the other hand, questionnaires suffer from low response rates, a lack of opportunity for follow-up clarification, and the risk that respondents may misinterpret questions. Designing an unambiguous questionnaire requires considerable skill, and pilot testing is strongly recommended to identify confusing items before full deployment.
问卷的优势包括每位受访者的成本低、匿名性（可能鼓励诚实反馈）以及易于对回答进行统计分析。另一方面，问卷存在回复率低、缺乏后续澄清的机会以及受访者可能误解问题等风险。设计一份无歧义的问卷需要相当大的技巧，强烈建议在大规模发放前进行试点测试以发现令人困惑的题目。
7. Observation Technique | 观察法
Observation involves the analyst watching users performing their daily tasks within the current system, recording workflows, bottlenecks, and behaviours without direct questioning. This technique is valuable because it reveals what people actually do rather than what they claim to do. People often underestimate or overestimate the frequency of certain tasks, and observation provides objective evidence. It is particularly effective in detecting informal workarounds and undocumented procedures.
观察法是指分析师观察用户在现有系统中执行日常任务，记录工作流程、瓶颈和行为，而不直接提问。这种技术很有价值，因为它揭示了人们实际做什么，而不是他们声称自己做什么。人们常常低估或高估某些任务的频率，而观察提供了客观证据。它在发现非正式的变通方法和未记录的流程方面尤其有效。
Observation can be either participant (the analyst becomes part of the work environment) or non-participant (the analyst remains a passive bystander). A key limitation is the Hawthorne effect: people may alter their behaviour when they know they are being watched, leading to unrepresentative data. Furthermore, observation is time-consuming and may not be feasible for tasks that occur rarely or require significant expertise to understand.
观察可以是参与式（分析师成为工作环境的一部分）或非参与式（分析师保持被动的旁观者）。一个关键的局限是霍桑效应：当人们知道自己被观察时，可能会改变自己的行为，导致数据不具有代表性。此外，观察耗时长，对于不常发生或需要较大专业知识才能理解的任务可能不适用。
8. Document Analysis | 文档分析
Document analysis involves examining existing written materials such as forms, reports, policy manuals, procedure guides, and system logs. These documents provide concrete evidence of how the current system operates and may reveal formal requirements that stakeholders have forgotten to mention. For example, analysing a company’s invoice forms can reveal the exact data fields, validation rules, and calculation methods required in the new system.
文档分析涉及检查现有的书面材料，如表单、报告、政策手册、程序指南和系统日志。这些文档提供了当前系统如何运行的具体证据，并可能揭示利益相关者忘记提到的正式需求。例如，分析一家公司的发票表单可以揭示新系统所需的精确数据字段、验证规则和计算方法。
Document analysis is relatively cheap, unobtrusive, and can be performed at any time without disturbing users. It is an ideal starting point before interviews and observations, allowing the analyst to become familiar with the domain. However, documentation may be outdated, incomplete, or inaccurate, and it does not capture informal processes or tacit knowledge. Therefore, document analysis is best used in combination with other techniques.
文档分析相对便宜、不干扰用户，并且可以在任何时间进行而不会打扰他人。它是访谈和观察之前理想的起始步骤，让分析师熟悉领域。然而，文档可能过时、不完整或不准确，而且无法捕捉非正式流程或隐性知识。因此，文档分析最好与其他技术结合使用。
9. Feasibility Study | 可行性研究
Before committing significant resources to development, an organisation must determine whether the proposed system is worth building. A feasibility study assesses the technical, economic, legal, and operational viability of the project. Technical feasibility examines whether the required hardware, software, and expertise are available. Economic feasibility, or cost-benefit analysis, compares the anticipated costs of development against the projected savings or revenue increases the system will deliver.
在投入大量资源进行开发之前，组织必须确定拟议的系统是否值得构建。可行性研究评估项目在技术、经济、法律和操作上的可行性。技术可行性检查所需硬件、软件和专业知识是否可获取。经济可行性，即成本效益分析，将预期开发成本与系统将带来的预计节省或收入增长进行比较。
Legal feasibility addresses compliance with regulations such as data protection laws, while operational feasibility considers whether users and management will accept the new system and whether it aligns with existing working practices. The feasibility study culminates in a feasibility report that recommends whether to proceed with development, modify the proposal, or abandon the project. In CIE examination questions, you should be prepared to discuss each type of feasibility and identify which one is most relevant to a given risk.
法律可行性涉及对数据保护法等法规的合规性，而操作可行性考虑用户和管理层是否会接受新系统以及系统是否与现有工作方式一致。可行性研究最终形成可行性报告，建议是继续开发、修改提案还是放弃项目。在CIE考试题目中，你应该准备好讨论每种类型的可行性，并识别哪种与给定风险最相关。
10. Requirements Specification | 需求规格说明
Once requirements have been gathered and analysed, they must be documented in a requirements specification. In software engineering practice, this document is often called a Software Requirements Specification (SRS). The SRS acts as a definitive reference for all future stages of development, including system design, coding, testing, and maintenance. It should be complete, consistent, unambiguous, and verifiable.
一旦需求被收集和分析，就必须将其记录在需求规格说明中。在软件工程实践中，该文档通常称为软件需求规格说明（SRS）。SRS是开发所有后续阶段（包括系统设计、编码、测试和维护）的权威参考。它应该是完整的、一致的、无歧义的和可验证的。
A well-structured SRS typically contains an introduction (purpose, scope, definitions), a description of the overall system context, the list of functional requirements (often numbered), the list of non-functional requirements, and assumptions or dependencies. Each requirement should be uniquely identified, for example FR-001, so that it can be traced through the development lifecycle. Traceability is invaluable during requirement changes and testing.
结构良好的SRS通常包含引言（目的、范围、定义）、系统整体环境的描述、功能需求列表（通常已编号）、非功能需求列表以及假设或依赖关系。每个需求都应有唯一标识，例如FR-001，以便在开发生命周期中进行跟踪。可追溯性在需求变更和测试期间非常有价值。
In the examination context, you may be asked to write a set of requirements for a given scenario. Practise converting a written description of a system into numbered functional and non-functional requirements. Use action verbs such as ‘must’, ‘shall’, and ‘should’ carefully—’must’ indicates a mandatory requirement, while ‘should’ suggests a desirable but optional one.
在考试背景下，你可能会被要求为给定场景编写一组需求。练习将系统的文字描述转换为编号的功能需求和非功能需求。谨慎使用“必须”、“应当（shall）”和“应该（should）”等动词——“必须”表示强制性需求，而“应该”表示可取但可选的。
11. Stakeholders and Their Perspectives | 利益相关者及其视角
Stakeholders are individuals or groups with an interest in the system. They include end users, managers, system administrators, investors, and external regulators. Each stakeholder group has different needs and priorities. End users focus on usability and efficiency, while managers care more about cost control and reporting capabilities. The analyst must actively engage with all stakeholder groups and mediate conflicts, as requirements may be contradictory across groups.
利益相关者是对系统有利益关系的个人或群体。他们包括最终用户、经理、系统管理员、投资者和外部监管机构。每个利益相关者群体都有不同的需求和优先事项。最终用户关注可用性和效率，而经理更关心成本控制和报告能力。分析师必须积极与所有利益相关者群体互动并调解冲突，因为各群体之间的需求可能相互矛盾。
For example, users might request a highly customisable interface, while the IT department insists on standardisation to reduce maintenance costs. The analyst’s role is to negotiate a solution that satisfies the critical needs of both parties within the project constraints. This negotiation process is an inherent part of requirements engineering and demonstrates the importance of soft skills, including communication, diplomacy, and conflict resolution.
例如，用户可能要求高度可定制的界面，而IT部门坚持标准化以降低维护成本。分析师的角色是协商一种解决方案，在项目约束范围内满足双方的关键需求。这一协商过程是需求工程的固有组成部分，体现了沟通、外交和冲突解决等软技能的重要性。
12. Validating Requirements | 需求验证
Validation ensures that the documented requirements accurately reflect the stakeholders’ true needs before development begins. Techniques for validation include user walkthroughs, in which stakeholders review the requirements document page by page, and prototyping, in which a working model of the system is built to clarify requirements. Validation differs from verification: verification checks that the system is built correctly (conforms to specification), while validation checks that the correct system is built (meets user needs).
验证确保在开发开始之前，文档化的需求准确反映了利益相关者的真正需求。验证技术包括用户走查（利益相关者逐页审查需求文档）和原型法（构建系统的工作模型以澄清需求）。验证（validation）与校验（verification）不同：校验检查系统是否正确构建（符合规格），而验证检查是否构建了正确的系统（满足用户需求）。
Requirements are rarely fixed at the outset; they evolve as stakeholders see early versions of the system. Formal change control procedures must be established to manage modifications to the baseline specification, ensuring that any change is assessed for its impact on cost, schedule, and other requirements. Rigorous validation reduces the risk of discovering serious defects during acceptance testing, where rectification is most expensive.
需求很少在一开始就固定；它们会随着利益相关者看到系统的早期版本而演变。必须建立正式的变更控制程序来管理基线规格的修改，确保任何变更都经过其对成本、进度和其他需求影响的评估。严格的验证可以降低在验收测试期间（此时纠正费用最高）发现严重缺陷的风险。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
屏轩国际教育cambridge primary/secondary checkpoint, cat4, ukiset,ukcat,igcse,alevel,PAT,STEP,MAT, ibdp,ap,ssat,sat,sat2课程辅导，国外大学本科硕士研究生博士课程论文辅导Cancel reply