Business requirements definition (業務要件定義) is the work of taking the problems found by analyzing current operations and clarifying the to-be state of the new business (procedures, roles and authority, business rules, and so on) along with the scope to be systematized.
Analyze current business
Define business requirements
System requirements definition
Software requirements definition
Finally, decide what the software itself will handle.
4 / 4
In the software life cycle (the flow from planning a system through development and operation), this work belongs to the requirements definition process (要件定義プロセス) that follows planning. Its aim is to make the scope of systematization and the functions needed there concrete, and to align understanding with stakeholders (the people and organizations involved with the system, such as the departments that will use it and the party placing the order).
AnalogyIt is like listing what is inconvenient about your current home before moving, then agreeing as a family on how you will live in the new one. Drawing the floor plan comes later.
Exam points
ExamRequirements are clarified in the order business requirements → system requirements → software requirements (業務要件 → システム要件 → ソフトウェア要件), starting from the side closest to the business.
ExamBusiness requirements (業務要件) describe business goals and the way of working that achieves them. They sit on a different layer from system requirements (システム要件), which describe the system's performance and methods.
ExamBusiness rules (業務ルール) that the system follows are clarified at the stage of defining business requirements. If this step falls short, the system gets built on a misreading of those rules.
Functional requirements (機能要件) define what the system does (the data it accepts, the processing it performs, and the screens and reports it outputs) to meet the business requirements.
Processing such as registering an order or totaling the amount to bill at month-end counts as a functional requirement. In other words, it takes the part of the business the system handles and writes it down as what the system does.
AnalogyFor a vending machine, these are the jobs the machine itself does: taking money, dispensing the product, and returning change.
Exam points
ExamWhich data the system accepts and which it returns, that is, the types of input and output data (入出力データの種類), determine what the processing does, so they belong to functional requirements (機能要件).
ExamDeciding which functions the system needs to support the business, and spelling out the scope of systematization, is the job of the requirements definition process (要件定義プロセス).
Non-functional requirements (非機能要件) define the conditions a system must meet beyond its functions themselves (quality levels such as performance, reliability, and security, plus technical and operational conditions).
Examples of non-functional requirements
Performance
Response time
Processing time
Reliability
Keeps running without stopping
Recovery time after a failure
Security
Data encryption
Access management
Operation and maintenance
Monitoring method
Ease of maintenance
How many seconds a screen takes to respond, how long the system may be down in a year, and how data is protected all fall here. Even for the same function, the required level changes the equipment and cost needed.
AnalogyFor the same vending machine, these are the conditions beyond the jobs it does: how many seconds after a button press the product comes out, how many years it runs without breaking down, and how often it is inspected.
Exam points
ExamAmong non-functional requirements (非機能要件), performance (性能) requirements describe processing speed, expressed as the response time (応答時間) to an operation or the time processing takes.
ExamAn upper limit on downtime per year and a target time to recover from a failure are quality conditions rather than system functions, so they belong to non-functional requirements (非機能要件).
ExamValues for non-functional requirements (非機能要件) such as response-time targets and operating hours are, like functions, decided in the requirements definition (要件定義) phase and agreed with the user department.
Agreement on requirements (要件の合意) means confirming the compiled requirements with stakeholders such as the user department, with both sides accepting that work will proceed on that basis, so that the requirements become final.
Compile requirements into a document
Users review them
Head of user department approves
Becomes the basis for development
The finalized requirements specification becomes the basis for deciding how much to build.
4 / 4
What has been agreed is recorded in a document such as the requirements specification (要件定義書), and later phases proceed on that basis. Moving into development without agreement makes it likely that mismatches with actual business practice surface after completion and force rework.
AnalogyIt is like a custom-built house: the owner and the builder meet repeatedly to settle the specifications, and finally the owner accepts the content and signs. After signing, construction follows those specifications.
How to rememberThe first character of 合意 (agreement) means to bring together. The builders and the users first bring the content together, and then the users' manager approves it to make it final.
Exam points
ExamThe one party whose agreement on business requirements cannot be left out is the head of the user department (利用部門の責任者) that will use the new system.
ExamEven when developers define the system requirements, users take part in the review (レビュー) to check that the requirements meet their own needs.
ExamThe agreed requirements specification (要件定義書) is the document that sets the scope of what will be developed.
Business requirements definition sets the to-be state of the business based on current-state analysis and makes the scope of systematization and the needed functions concrete.
Many non-functional targets can be expressed as numbers, so pin down figures such as response speed and allowable downtime.
Requirements are put in writing and become final once the head of the user department approves them.
Moving into development with vague requirements increases rework in later phases.