Highlighted text? Practice this concept. Highlighted passages and figures open related questions.
Practice related questions (1)Progress & bookmarks
Current section
1-2-1 Software Requirements Definition Process
p. 246
Practice this section 1 linked exam question with default filters
Progress
Not marked complete
Related questions in this lesson 2
Software quality and reliability2p. 246 · PDF 250
1-2-1 Software Requirements Definition Process
In the software requirements definition process, the requirements for software configuration items are converted to technical requirements (i.e., software requirements) usable in design of the software.
[Activities of software requirements definition process] (i) Establishment of software requirements (ii) Evaluation and review of software requirements Note: In the Common Frame 2013 software implementation process, (i) and (ii) are treated as a single activity. In this textbook, they are separated for ease of understanding.
p. 247 · PDF 251
(1) Establishment of software requirements
In the establishment of software requirements, the requirements allocated to software configuration items are analyzed, software requirements are clarified as described below, and these are documented as software requirements definitions.
[Software requirements]
- • Functional
and capability specifications, including performance, physical characteristics, and environmental conditions under which the software item is to perform - • External interfaces of the software items
- • Qualification requirements (development of the software qualification testing
specifications) - • Safety specifications, including those related to methods of operation and
maintenance, environmental influences, and personnel injury - • Security specifications, including those related to the leakage of information
- • Human-factors engineering specifications, including those related to manual
operations, human-equipment interactions, constraints on personnel, and areas needing concentrated human attention, that which sensitive to human errors and training - • Data definition and database requirements
- • Installation and acceptance requirements of the delivered software product at the
operation and maintenance sites - • User documentation requirements
- • User operational and execution requirements
- • User maintenance requirements
In the establishment of software requirements, a business model that portrays the business and a logical data model that portrays data to be handled are created. Determination of specifications for functions and capabilities required of the software is performed, along with interface design. At the same time, software qualification requirements, for confirming whether requirements are fulfilled, are defined. With regard to software requirements, it is considered advisable to also determine the order of implementation priority. It is noted that quality characteristic specifications of the software to be developed are also included in software requirements. The software quality characteristics defined in ISO/IEC 9126 (JIS X 0129-1) are used as guidelines for specifying the quality characteristics of software.
p. 248 · PDF 252
| Quality Characteristics | Overview |
|---|---|
| Functionality | The capability of the software product to provide functions which meet stated and implied needs when the software is used under specified conditions [Sub-characteristics] Suitability, accuracy, interoperability, security |
| Reliability | The capability of the software product to maintain a specified level of performance when used under specified conditions [Sub-characteristics] Maturity, fault tolerance, recoverability |
| Usability | The capability of the software product to be understood, learned, used, and attractive to the user, when used under specified conditions [Sub-characteristics] Understandability, learnability, operability, attractiveness |
| Efficiency | The capability of the software product to provide appropriate performance, relative to the amount of resources used, under stated conditions [Sub-characteristics] Time behavior, resource behavior |
| Maintainability | The capability of the software product to be modified. The capability to adapt the software product to corrections/improvements of functions, changes in environment, and changes in requirements specifications [Sub-characteristics] Analyzability, changeability, stability, testability |
| Portability | The capability of the software product to be transferred from one environment to another [Sub-characteristics] Adaptability, installability, co-existence, replaceability |
In business operations modeling to create business models or data modeling to create logical data models, business analysis is performed by using methods described below.
- • Hearing
This is a method of hearing comments from users and others in order to clarify the requested particulars of software or work. Hearings are implemented on the basis of hearing planning that includes the subjects and objectives of the hearings, and the results are documented in hearing minutes. - • Use case
p. 249 · PDF 253
This is a method used to define the associations and relationships between systems and actors (e.g., outside persons or machines that boot the system, interact with information).
- • Mock-up and prototype
This is a method of verifying and evaluating validity of specifications, oversights, feasibility, and others by creating mock-ups or prototypes. - • Diagramming method
This is a method of diagramming and verifying business processes and others. Typical diagramming methods include DFD, which focuses on the flow of data to represents business processes; E-R diagrams, which abstract the information handled in business to represent it as entities and relationships among entities; UML, which uses object-oriented concepts in representation; and decision tables, which summarize complex conditions and others in table format. (Details of diagramming methods are described in “2-2 Software Design Technique.”)
In addition, form design and slip design, which define the forms and slips used in business in formats adapted to the system, may be performed in data modeling.
- • Form design
This designs the items and layout of forms (e.g., reports). In form design, the purpose of forms, the period of use, where forms will be used, and others are considered comprehensively. Then, necessary items and layouts are determined. - • Slip design
This designs the items and layout of slips (e.g., sales slips). Since slips are used for data input into the system, and others, items and layouts are to be determined in consideration of ease of use (e.g., ease of understanding input items) for the user.
If necessary, code design may be performed at this time. (For example, in slip design, managing customers by customer code and entering the code may be deemed easier than entering a customer’s name and address.)
- • Code design
This selects the target items with a code, and creates a code table for each target item. Since code includes sequence code, block code (or classification code), group classification code, mnemonic code, synthetic code, and many other types, appropriate code is to be selected.
p. 250 · PDF 254
However, data modeling is to be performed for the purpose of clarifying the functions and capabilities of software items, external interfaces, and others. For that reason, form design, slip design, code design, and others do not need to be rigidly performed at this time. Moreover, as database requirements and definition of the data to be clarified on the basis of these results are for the purpose of gaining a conceptual image of data to be used in the system, the file organization method for recording data, normalized database tables, and others do not need to be determined.
(2) Evaluation and review of software requirements
Two tasks are executed in evaluation and review of software requirements.
(i) Evaluation of software requirements
Defined software requirements are evaluated, with consideration given to the criteria of traceability to system requirements and system design, external consistency with system requirements, internal consistency, testability, feasibility of software design, and feasibility of operation and maintenance. (ii) Implementation of joint review of software requirements A joint review is conducted, and agreement is obtained concerning software requirements.
Section progress
Original chapter exercises
Original chapter exercises →New FE Textbook Vol.2 · First Edition, April 2015