Requirements Definition: From Hearing to Specification

Cases of project failures due to inadequate requirements definition continue to occur.

Director A of a web development company had a painful experience with a corporate website renewal project. After receiving a request from a client to "create a modern, highly usable website," he accepted the project for 3 million yen. However, during development, additional requests emerged one after another: "We also want e-commerce functionality," "Multi-language support is also needed," and "We'd like to add membership features." Ultimately, the development workload became three times the original estimate, and negotiations for additional costs also stalled. The project was delayed by over a year, and A's company incurred a loss of 2 million yen.

On the other hand, clients also suffer serious losses. The information systems manager at mid-sized manufacturing company B had a bitter experience with a core system renewal project. He requested a development company to "migrate the current system functions to the new system as-is," but detailed specifications of the existing system were unclear, causing significant delays in migration work. The new system's operation was delayed by six months, resulting in an opportunity loss of 30 million yen.

What these problems have in common is perception gaps during the requirements definition stage. The client's true issues and constraints are not clarified, and contractors cannot accurately estimate technical feasibility and workload. As a result, projects proceed in completely different directions than both parties anticipated.

Requirements definition failures don't stop at mere budget overruns or delivery delays. Clients fail to achieve expected results, and contractors cannot secure profits. More seriously, the breakdown of trust relationships causes long-term opportunity losses. Mastering proper requirements definition processes is an important management issue for freelancers, development companies, and client organizations alike.

Perception gaps in requirements definition are not accidental problems but occur inevitably due to structural causes.

Structural Issues on the Client Side

Many clients cannot accurately verbalize their company's business processes and challenges. Being immersed in daily operations, they overlook work procedures and exception handling that have become tacit knowledge. For example, even a client saying "We want to build a customer management system" actually has dozens of detailed requirements such as customer classification methods, sales representative assignment rules, and integration methods with existing Excel files. However, clients perceive these as "natural assumptions" and don't explicitly communicate them.

Additionally, clients often don't understand technical constraints. While the request to "create a site like Amazon for 1 million yen" is extreme, clients who don't recognize the gap between feasibility and budget are not uncommon. Integration with existing systems, security requirements, and operational maintenance workloads are also often underestimated.

Furthermore, consensus building within client organizations is often inadequate. While staff-level personnel envision a "simple system," management may prioritize "future scalability." Cases where additional requirements emerge from upper management during projects, necessitating major requirement changes, occur frequently.

Structural Issues on the Contractor Side

Contractors also tend to underestimate requirements definition. Particularly freelancers and small development companies often adopt an attitude of "let's secure the contract first and decide details later." There are also structural problems where they cannot adequately estimate requirements definition workload due to price competition with competitors.

Contractors with technical backgrounds often lack understanding of client business operations. While they may be well-versed in technical aspects of system development, they don't deeply understand client industry knowledge or business flows. As a result, they overlook business requirements that clients take for granted, necessitating major specification changes later.

Additionally, contractors tend to make optimistic estimates. While something being technically feasible and being achievable within planned workload are separate issues, pressure to win contracts causes them to underestimate the latter. Particularly for projects using new technologies, they tend to underestimate learning costs and trial-and-error time.

Information Asymmetry and Consensus Building Difficulties

Serious information asymmetry exists between clients and contractors. Clients know business details but not technology, while contractors know technology but not business operations. To bridge this information gap, both parties need to meet halfway and share each other's knowledge. However, in reality, adequate information sharing doesn't occur due to time and cost constraints.

Furthermore, consensus building processes are often unclear. Verbal meeting content isn't documented, leading to later disputes of "I never heard about that." Decision criteria and approval processes for requirement changes are also ambiguous, causing confusion during projects.

To solve these structural issues, it's essential to systematically organize requirements definition processes and have both contractors and clients use common procedures and tools.

Effective requirements definition hearing is achieved through a structured approach.

Stage 1: Clarifying Issues and Objectives

In the first stage of requirements definition hearing, clarify the client's fundamental issues and objectives. It's important to discover the true challenges behind superficial requests like "We want to create a website" or "We want to implement a system."

Specific question examples include:

• "What business problems are you currently experiencing?"
• "How much cost or time loss does this problem cause?"
• "What would the ideal state look like when the problem is resolved?"
• "Why are you considering systemization at this timing?"

What's important is not accepting client statements at face value but exploring deeper backgrounds. For example, for a request to "improve work efficiency," ask quantitative questions like "Which work takes the most time?" "Who feels how much burden from that work?" "How many hours per month do you want to reduce through efficiency improvements?"

At this stage, contractors must not present solutions. Proposing technical solutions before fully understanding client challenges may cause overlooking essential issues.

Stage 2: Detailed Understanding of Current Business Operations

Once issues and objectives are clarified, gain detailed understanding of current business processes. At this stage, organize the client's business flows chronologically, specifically identifying stakeholders, tools used, decision criteria, and exception handling.

An effective hearing technique is the "experiencing a day of business operations" approach. For example, when defining customer management system requirements, ask questions like:

• "How do you check customer information from when you arrive at work in the morning?"
• "When there's an inquiry from a new customer, what procedure do you follow?"
• "What's the response flow when there's a complaint from an existing customer?"
• "What procedure do you follow for month-end sales aggregation?"

What's important is understanding business operations including exception handling and special cases. While 80% of regular business can be processed with standard procedures, the remaining 20% of exception handling is often the most workload-intensive part. You need to specifically confirm "occasionally occurring cases," "seasonally fluctuating operations," and "emergency responses."

Hearing from stakeholders is also important. Not just the contact person serving as the ordering party, but also field staff who will actually use the system, supervisors with approval authority, and personnel from related departments. Requirements often differ by position, and if not coordinated in advance, major specification changes will occur later.

Stage 3: Confirming Technical Requirements and Constraints

Once business requirements are clarified, confirm technical constraints and non-functional requirements. At this stage, utilize contractor expertise to identify technical challenges that clients might overlook.

Technical requirements to confirm include:

• Security requirements (personal information handling, access restrictions, data encryption, etc.)
• Performance requirements (concurrent connections, response time, data capacity, etc.)
• Operational requirements (backup, failure response, maintenance methods, etc.)
• Integration requirements (data integration with existing systems, external API connections, etc.)
• Environmental requirements (browsers used, smartphone support, internal network restrictions, etc.)

Confirming constraints is also important. Specifically understand budget, delivery deadlines, human resources, and technical limitations. Particularly clearly distinguish between "absolutely non-negotiable conditions" and "adjustable conditions," and determine priorities.

At this stage, contractors explain technical options and their respective merits and demerits. It's important to explain in an understandable way without using technical jargon so clients can make technical decisions.

Stage 4: Requirement Prioritization and Consensus Building

In the final stage, prioritize identified requirements and determine implementation scope. Since realizing all requirements simultaneously is often difficult due to budget and deadline constraints, classify them into "essential functions," "important functions," and "nice-to-have functions."

Use frameworks like MoSCoW method (Must have, Should have, Could have, Won't have) to systematically organize requirements. Clients and contractors jointly determine priorities and develop phased development plans.

For consensus building, it's important to document in the form of a requirements definition document and have both parties sign. Verbal agreements cause disputes later, so always confirm in writing. Also agree in advance on procedures and cost calculation methods when requirement changes occur.

Requirements definition hearing is a time-consuming and costly process, but this investment can significantly reduce risks in later phases. The key to success is active participation by both contractors and clients and careful progression.

Specification creation is an important process that translates requirements definition results into concrete design.

Specification Structure and Essential Items

Effective specifications are created with the following structure:

1. Project Overview (2-3 pages)

• Project purpose and background
• Quantitative organization of issues to be resolved
• Success indicators and their measurement methods
• Project structure and responsibility allocation
• Overall schedule and major milestones

2. Functional Specifications (60-70% of total)

• Function list and priorities
• Detailed specifications for each function (input, processing, output)
• Screen transition diagrams and wireframes
• Database design overview
• External system integration specifications

3. Non-functional Specifications (20-30%)

• Performance requirements (response time, concurrent connections, etc.)
• Security requirements (authentication, encryption, access control, etc.)
• Availability requirements (uptime, failure recovery time, etc.)
• Scalability requirements (support for future function additions, etc.)
• Operational requirements (backup, monitoring, maintenance, etc.)

4. Constraints and Prerequisites (10%)

• Technical constraints (technologies used, environmental limitations, etc.)
• Budget, deadline, and human resource constraints
• Legal and regulatory constraints
• Constraints with existing systems

In actual development environments, the description method for functional specifications is most important. Ambiguous expressions cause interpretation differences later, so describe specifically in the following format:

Function Name: Customer Search Function
Overview: Search customers matching conditions from customer database
Input: Customer name (partial match allowed), customer code (exact match), registration date (period specification allowed)
Processing: Search database with input conditions and retrieve matching customer list
Output: Customer list (display customer code, customer name, phone number, last transaction date)
Constraints: Display maximum 100 search results; show warning if exceeding 100
Exceptions: Display "No matching customers found" when 0 customers match

Practical Procedures for Specification Creation

Specification creation proceeds with the following procedures:

1. Requirement Organization and Structuring (1-2 days) Classify hearing results into functional requirements, non-functional requirements, and constraints, and organize relationships. Visualize the overall picture of requirements using mind maps or flowcharts. At this stage, discover requirement gaps or contradictions and determine the need for additional hearing.

2. Function Design and Wireframe Creation (3-5 days) Determine detailed specifications for each function and conduct screen design. Create wireframes using tools like Figma, Adobe XD, or Balsamiq. At this stage, design considering both usability and technical feasibility.

3. Technical Design and Non-functional Specification Determination (2-3 days) Conduct system configuration, database design, and security design. Determine the technology stack to use and design architecture that meets performance requirements. At this stage, design considering operational and maintenance aspects.

4. Specification Documentation (2-3 days) Document design content as specifications. Add explanations for technical terms so not only engineers but also clients can understand. Actively use diagrams and flowcharts to create visually understandable specifications.

5. Review and Consensus Building (1-2 days) Review completed specifications with both clients and contractors, and identify correction points. Particularly for functional specifications, detailed confirmation by client business personnel is important. Finally obtain written agreement and finalize specifications.

Quality Standards and Check Points

To ensure specification quality, establish the following check points:

Completeness Check

• Are all functional requirements specified?
• Are non-functional requirements expressed with specific numerical values?
• Are exception handling and error handling clearly stated?
• Are external system integration specifications detailed?

Consistency Check

• Is consistency maintained between functions?
• Are there no contradictions in data flow?
• Are security requirements unified throughout?
• Are term definitions unified?

Feasibility Check

• Is it technically feasible?
• Can it be implemented within budget and deadline constraints?
• Is the design realistic for operations and maintenance?
• Is future scalability considered?

Understandability Check

• Can clients understand the specifications?
• Can third parties implement based on reading the specifications?
• Are diagrams appropriately used?
• Are technical terms appropriately explained?

Specification creation is the most important deliverable in the requirements definition process. To prevent rework in later phases, spending sufficient time creating high-quality specifications is key to project success.

In actual requirements definition, there are pitfalls that even experienced practitioners commonly fall into.

The "Obvious" Trap: Overlooking Tacit Knowledge

The most frequent problem is perception gaps regarding matters both clients and contractors consider "obvious."

On the client side, they treat their company's business flows as "common sense" and omit detailed explanations. For example, behind a request for "invoice issuing functionality," complex approval flows often exist. A five-stage process of "staff creates invoice → section chief confirms content → department head approves amount → accounting performs final check → system automatically issues" is expressed by clients in one phrase: "invoice issuance."

On the contractor side, they also consider specifications based on technical "common sense." When hearing "user authentication function," they assume username and password login functionality, but clients may be expecting IC authentication using employee ID cards. Such differences in technical assumptions lead to major specification changes later.

As a countermeasure, it's important to establish a "prerequisites" chapter in requirements definition documents and document both parties' assumptions. Also, when statements like "that's natural, right?" or "we normally do it this way, right?" occur, always specifically confirm that content.

Scope Creep: Unlimited Requirement Expansion

Scope creep is a phenomenon where clients continuously add requests during requirements definition, making it impossible to stay within the original budget and deadline. Particularly in web development requirements definition, cases frequently occur where clients see other companies' sites and add requests like "we want this too" and "that's also necessary."

For example, in corporate site renewal requirements definition, what started as a three-page structure of "company overview, business introduction, contact" expands with requests like "we also want to include case studies," "we want to add blog functionality," "multi-language support is also needed," and "we also need smartphone app integration."

Contractors also tend to easily accept requests due to expectations of differentiation from competitors and additional sales. However, accepting requests without adjusting budget and deadlines will inevitably cause project failure.

To prevent scope creep, it's important to clearly distinguish and document "what will be realized in this project" and "what is out of scope for this time" in the early stages of requirements definition. When additional requests emerge, always calculate impact scope (workload, budget, deadline) and respond through formal change procedures.

Premature Technology Selection

Contractors sometimes proceed with requirements definition assuming implementation with familiar technologies before requirements are clarified. Technical assumptions like "building with WordPress" or "using React" hinder consideration of truly necessary functions.

For example, while proceeding with corporate site requirements definition assuming WordPress, it later became clear that multi-site functionality and complex approval workflows were needed, making implementation difficult with WordPress. Reconsidering from requirements definition became necessary to redo technology selection.

The appropriate approach is to conduct technology selection after sufficiently identifying requirements. The sequence of selecting optimal technology for requirements and then adjusting specifications based on technical constraints is important.

Neglecting Usability

Requirements definition tends to focus on functional requirements while neglecting actual ease of use. Clients think "having this function would be convenient," and contractors consider specifications from the perspective of "technically implementable." However, whether the system is actually user-friendly is a separate issue.

For example, a sales management system incorporated "customer information, project information, schedule management, sales management" functions, but in actual use, screen transitions were complex and it wasn't used in daily operations. Despite rich functionality, low usability caused a return to Excel management.

To ensure usability, it's important to set personas (typical user profiles) during requirements definition and design systems according to those users' business flows. Also, create prototypes for actual users to test and verify ease of use.

Overlooking Operations and Maintenance Requirements

Requirements definition tends to focus on development-time functionality while neglecting post-system operation and maintenance requirements. The perception that "making and delivering the system is the end" causes serious problems after operation begins.

Specifically, the following operational requirements are easily overlooked:

• Data backup frequency and recovery procedures
• Contact system and response procedures during system failures
• Regular maintenance implementation methods
• User addition and deletion management methods
• Security patch application procedures

Building systems without clarifying these operational requirements in advance makes responding to troubles difficult after operation begins. Additionally, operational costs exceed expectations, pressuring client budgets.

It's important to consider the entire system lifecycle during requirements definition and examine operational and maintenance requirements. Include creation of operational manuals and education of operational staff in requirements planning.

Inadequate Consensus Building Processes

In requirements definition, different requests come from multiple client stakeholders (field staff, managers, executives), but consensus building processes to coordinate these are often unclear. As a result, conflicts between stakeholders surface during projects, necessitating major requirement reviews.

To facilitate smooth consensus building, it's important to clarify decision-making processes in the early stages of requirements definition and identify final approval authorities. Also, agree in advance on procedures and cost burden when requirement changes occur.

To avoid these pitfalls, it's effective to systematize requirements definition processes and use checklists to prevent omissions. Rather than relying on empirical rules, proceeding with requirements definition through structured approaches is key to project success.

This section presents specific actions that both contractors and clients should practice to succeed in requirements definition.

Action Guidelines for Contractors (Freelancers and Development Companies)

1. Appropriate Workload Allocation for Requirements Definition Allocate 20-30% of total project workload to requirements definition. For a 3-month development project, dedicate 2-3 weeks to requirements definition. This investment significantly reduces rework in later phases.

Clearly state requirements definition workload in estimates and seek client understanding. Show breakdowns like "Requirements Definition: 300,000 yen, Design/Development: 2,000,000 yen, Testing/Delivery: 700,000 yen" and explain the importance of requirements definition.

2. Systematizing Hearing Tools Prepare the following tools for effective hearing:

• Hearing sheets (customized by industry)
• Requirements organization templates (functional, non-functional, constraints)
• Priority matrix (importance × urgency)
• Risk management tables (technical, schedule, budget, operational)

These tools prevent hearing omissions and help structure and organize requirements.

3. Utilizing Prototyping Create simple prototypes during requirements definition to align understanding with clients. Use tools like Figma, Adobe XD, or InVision to create interactive mockups.

Prototypes can concretely show operability and screen transitions that are difficult to convey through documents. They also make it easier to receive client feedback, improving requirement accuracy.

4. Risk Management and Alternative Plan Preparation During requirements definition, identify technical risks, schedule risks, and budget risks, and prepare alternative plans for each.

For example, prepare alternatives like "if external API integration doesn't proceed as scheduled, substitute with CSV integration" or "if advanced functions exceed budget, respond with phased implementation."

5. Continuous Agreement Confirmation Requirements definition doesn't end with one-time determination but requires continuous agreement confirmation during the development process. Confirm requirement changes in weekly progress reports, and immediately calculate impact scope when changes occur.

Create a requirements change management table recording change content, impact scope, response methods, and additional costs. This prevents additional cost billing troubles at project completion.

Action Guidelines for Clients (Companies and Organizations)

1. Pre-implementation of Internal Consensus Building Before starting requirements definition, reach agreement among internal stakeholders on basic policies. Coordinate opinions of field staff, managers, and executives to form unified views on project objectives, budget, deadlines, and success indicators.

Clarify decision-making processes and identify approval authorities for requirement changes. Establish criteria like "field-level changes require section chief approval," "budget-affecting changes require department head approval," and "major specification changes require executive approval."

2. Business Process Visualization Before hearing with contractors, organize and document your company's business processes. Diagram current business flows and clarify stakeholders, tools used, decision criteria, and exception handling.

Particularly identify and document business rules that have become tacit knowledge and person-dependent processing. Include "special processing only veteran employees know" and "special rules only during busy periods."

3. Clarifying Constraints Specifically organize budget, deadlines, human resources, technical constraints, and legal constraints, and communicate them to contractors. Clearly distinguish between hopes like "we'd like to..." and constraints like "absolutely must be..."

Also explain in detail integration constraints with existing systems, internal security policies, and industry regulations. Communicating these constraints later necessitates major specification changes.

4. Active Participation in Requirements Definition Don't leave requirements definition entirely to contractors but actively participate as the client. Have practical staff attend hearings to directly communicate field voices.

For requirements definition document reviews, don't just perform formal checks but verify business requirement validity in detail. Examine from perspectives like "will this function really improve business operations?" and "is the operational burden realistic?"

5. Phased Requirements Determination Don't try to determine all requirements at once but adopt a phased approach. Plan to determine core functions in phase 1 and add peripheral functions in phase 2.

Detail high-priority functions first and adjust implementation scope according to budget and deadlines. Create flexible plans like "essential functions are definitely implemented, additional functions are handled if budget allows."

Common Action Guidelines

1. Optimizing Communication Frequency During requirements definition periods, set regular meetings 2-3 times per week to share progress and challenges. Emphasize face-to-face (or video conference) communication, not just email or chat.

Always create meeting minutes clearly stating decisions, pending items, and actions until next meeting. Verbal promises cause disputes later, so confirm important agreements in writing.

2. Utilizing External Experts When complex requirements or new technologies are involved, utilize external experts or consultants. Particularly for projects involving industry-specific requirements or regulations, specialized knowledge in relevant fields is essential.

Expert participation improves requirements definition quality and reduces risks in later phases. While costly, it's a worthwhile investment compared to losses from project failure.

3. Systematizing Continuous Improvement Create mechanisms to continuously improve the requirements definition process itself. Conduct retrospectives after project completion to identify challenges and improvements in requirements definition.

For next projects, improve requirements definition processes utilizing current experience. This cycle continuously enhances organizational requirements definition capabilities.

Requirements definition success is achieved through cooperation between contractors and clients. Both parties taking responsibility and proceeding with systematic approaches leads to successful web development and system development projects.