Functional requirements (機能要件) define what the system does: the processes and functions it provides for the business.
Requirements definition analyzes business workflows and usage to list the processing the system will take on. In a library lending system, for example, "record a loan by member number" and "list books past their return date" are functional requirements. The finer naming scheme for phases includes system requirements definition (システム要件定義), which covers the whole system, and software requirements definition (ソフトウェア要件定義), which covers the software inside it.
AnalogyIt is like the list of dishes on a restaurant menu. It fixes what the restaurant can serve, but says nothing yet about how to cook them.
Exam points
ExamSystem requirements definition (システム要件定義) clarifies the functions and performance the system must have, and the scope of what will be systematized is also fixed at this stage.
ExamSoftware requirements definition (ソフトウェア要件定義) clarifies the data items and their definitions the software handles. Working out processing logic and writing code belong to the later design and programming phases.
ExamThe ordering party checks that the delivered product has the functions in the specification, and the user department checks that the system meets the business requirements. Checking that each program works as designed is the development side's job.
Non-functional requirements (非機能要件) set the level and conditions at which functions are provided, such as response speed, resistance to outages, security, and ease of operation.
Viewpoint
Example requirement
Performance
Month-end closing finishes within 4 hours overnight
Reliability / availability
No downtime during business hours, except planned outages
Security
Only the staff in charge can view customer information
Operation and maintenance
The cause of a failure can be traced from logs
Like functional requirements, non-functional requirements get their targets during requirements definition. Stating targets in a checkable form, such as numbers, makes it easier to judge later whether they were met.
AnalogyIt is like a restaurant promising to serve food within 10 minutes of the order. It sets the standard of service, not the kinds of dishes.
How to rememberThe "non-" does not deny the functions; it points to conditions other than the functions themselves. Read it as conditions attached once the functions are in place.
Exam points
ExamPerformance targets, such as a target response time (応答時間), are set in system requirements definition (システム要件定義). They are not put off until the design stage.
ExamSystem testing (システムテスト), which checks the whole developed system, confirms not only that functions work correctly but also that non-functional requirements such as performance are met.
Mix-upFunctional requirements (機能要件) define the processing itself that the business needs, while non-functional requirements define the level and conditions that processing must meet in performance, reliability, security, operation, and so on.
Quality characteristics (品質特性) sort software quality into viewpoints, such as how easy it is to use and how rarely it fails.
Characteristic (JIS X 25010:2013)
What it looks at
Functional suitability
Has the needed functions and gives correct results
Performance efficiency
Response speed and resource use are appropriate
Compatibility
Coexists with other systems and exchanges information
Usability
Easy for users to learn and operate
Reliability
Keeps running normally and recovers when problems occur
Security
Protects information from unauthorized use
Maintainability
Easy to fix and change
Portability
Still runs after moving to another environment
The JIS X 25010:2013 standard divides quality into 8 characteristics, while earlier standards used 6. Functionality in the earlier standard roughly matches functional suitability in JIS X 25010. Splitting a vague sense of "good quality" into viewpoints makes targets easier to set when defining requirements, and lets the finished product be judged viewpoint by viewpoint.
AnalogyIt is like a scorecard that rates a car item by item: fuel economy, ride comfort, few breakdowns, and ease of servicing.
Exam points
ExamUsability (使用性) is the characteristic of whether users can learn the system easily and use it well with little effort. It concerns where users meet the parts of the system they operate, such as screens.
ExamFunctionality (機能性) is the property of producing correct results as specified, and reliability (信頼性) is the property of keeping normal operation despite incorrect input or failures.
Functional design (機能設計) is the design phase that decides user-visible specifications, such as screens and forms, from the results of requirements definition; it is also called external design.
Requirements definition
Functional design
Detailed design
Programming
Programming: write the decided processing steps in a programming language.
4 / 4
Functional design decides the items and layout of the screens users operate, the format of output forms, and the flow of user operations. Because users can see and check these specifications, gaps from what they asked for are easy to spot at this stage.
AnalogyIt is the stage in building a house where floor plans and exterior drawings are made from the owner's wishes. These are drawings the residents can look at to check how livable the house will be.
Exam points
ExamDeciding which items go on screens and forms, and their layout and format, is external design (外部設計), in other words functional design.
ExamSystem architecture design (システム方式設計) is a phase in the finer naming scheme that allocates requirements to hardware, software, and manual work and decides the configuration of equipment and networks. It does not decide user-visible specifications and is not another name for functional design.
Detailed design (詳細設計) is the design phase that refines the specifications from earlier design into internal specifications detailed enough to write programs.
In the finer naming scheme, the software detailed design (ソフトウェア詳細設計) stage decides the processing steps and data handling for each program to be coded. The results are compiled into design documents that programming then relies on.
AnalogyIt is like construction drawings that add pillar positions and the routes of wiring and piping to the floor plan. They are detailed enough for workers to start building right away.
Exam points
ExamWhat software detailed design (ソフトウェア詳細設計) decides for the first time is the specification of each individual program. In the next phase, programmers write the programs from that design document.
ExamWorking out how a program branches for each condition and drawing it as a flowchart (流れ図) takes place in the software detailed design stage.
Mix-upFunctional design (機能設計) decides the outside users see, such as screens and forms, while detailed design decides the inside developers build, such as program processing steps.
After requirements definition, before detailed design
Last step of design, followed by programming
Key points
Development first decides "what to build" in requirements definition, then refines "how to build it" step by step in design, and moves on to programming.
To match a description to a quality characteristic, look at the property it expresses, such as ease of use, resistance to failure, or running in another environment.
Phase names follow two schemes: a coarse one, as in this unit's figure, with requirements definition, functional design (external design), and detailed design, and a finer one with names such as system requirements definition and system architecture design. Their boundaries do not map one to one, so reason about phase order within one scheme at a time.