Inadequate requirements cause many problems in software products. This paper reports on an experiment to reduce the number of requirement defects. We analysed the present defects in a real-life product and estimated the likely effect of 44 prevention techniques. We had hoped a novel combination of techniques would come up, but the best approach was quite well known, although new to the company: study the user tasks better, make early prototypes of the user interface, and test them for usability. This approach was tried out in a new development project in the same company. Due to the new approach, there was no doubt about requirements during programming, and as a result it became the first project in the company that was completed on time and without stress. Usability was drastically improved, and as a result the product sold twice as many units as similar products, and at twice the unit price.

I E E E S O F T W A R E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y 0 7 4 0 -7 4 5 9 / 0 3 / $ 1 7 . 0 0 © 2 0 0 3 I E E E R equirements form a software system's foundation. Functional requirements indicate what the system shall do, data requirements indicate what it shall store, and quality requirements indicate how quickly or how easily it shall perform. This article focuses on functional requirements, which usually describe a system's input, output, and the relationship between the two. Traditional functional requirements specify the system's role but ignore the system's context. To solve that problem, requirements Use Cases versus Task-Based Descriptions Hotel system Receptionist UML use case diagram: Human and computer separated: Task descriptions. Split postponed: (1) Booking Check-in Checkout Hotel system Receptionist (2) Booking Hotel system (3) Booking Receptionist Figure A. Use cases versus tasks: (1) a Unified Modeling Language use case diagram, which deals only with the computer system's actions; (2) a use case that specifies separate human and computer actions; (3) task descriptions, which do not separate human and computer actions. 6 I E E E S O F T W A R E h t t p : / / c o m p u t e r. o r g / s o f t w a r e

When buying COTS-based software, the customer has to choose between what is available. The supplier may add some minor parts, but not everything the customer wants. This means that the customer cannot write down his requirements and expect that they can all be met. A scoring system is necessary rather than traditional mandatory requirements. Requirements for integrating the new COTS system with other systems are particularly hard because suppliers may integrate in different ways and with different other systems. A related problem is that once the new COTS system is purchased, the COTS supplier may have a de-facto monopoly. Only he can expand the system or integrate it with other systems. Experience shows that customers fail to deal with these issues adequately. As an example they may believe that asking for open interfaces is sufficient to guard them against monopoly. In this paper we analyze the problems and show ways to deal with them. We illustrate the problems and solutions with real-life examples from Electronic Patient Recording systems (EPR).

This case demonstrated a patient with a left-sided skin defect (SCS) and a left-sided local malformation in her dentition. It is possible that there is a developmental connection between these two left-sided defects, both with an ectodermal origin.

Objective: To compare the root development and the growth rate of the mandibular third molar (M3 inf) in individuals where the M3 inf erupted vs individuals exhibiting M3 inf impaction. Materials and Methods: Serial standardized intraoral radiographs (Eggen technique) were taken annually of the mandibular third molar region from 132 subjects (71 male and 61 female) from 15 to 20 years of age. Based on the films, 264 lower third molars were classified into an eruption and an impaction group. Root development was recorded according to a quantitative method described by Haavikko (1970), and the eruption status was analyzed using logistic regression. Results: In total, 155 (59%) of the M3 inf erupted, and 109 (41%) were impacted at age 20. In 44 (33%) patients both M3 inf were impacted, in 21 (16%) patients one tooth was erupted and the contralateral tooth impacted, and in 67 (51%) patients both M3 inf were erupted. The more mature a tooth was at age 15, the higher was the probability of eruption (odds ratio: 3.89, P , .001). The growth rate of the root development stage was statistically significantly associated with the probability of eruption (odds ratio: 10.50, P 5 .041). Conclusions: Delayed mandibular third molar root development is associated with impaction. Radiographs taken at age 15 may predict the risk of impaction and thereby guide decision making for the orthodontist or the oral and maxillofacial surgeon. (Angle Orthod. 2013;83:3-9.)