![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
Why is it that many software developers don't pay enough attention to requirements engineering? Are there ever circumstances where you can skip it?
What are the four design models required for a complete specification of a software design? Describe the role of one of them in your own words.
The four design models are data design, architectural design, procedural design, and interface design.
In the process of data design, you need to define data models, entity types, attributes, and relationships. To design relational database, which is the most widely used data model, you will create data specification such as data definitions and E-R diagrams.
You can use different data models depending on types and purposes of data. If you need to read and write database records very often, for instance, if you treat HTTP sessions in a database, key-value stores can be more faster. In case you analyze large amounts of numerical data such as point-of-sales data, column-oriented data warehouse is more efficient.
Describe the worst interface you have ever worked with and the best interface you have ever worked with.
The worst interface that I have ever used is the Japanese feature phone, and the best interface I have ever used is iPhone.
I first started to have a feature phone when I was 15 years old. That had very useful functions other than telephone and e-mail. For example, I could enjoy the mobile Web and purchase a variety of ring tones.
However, because feature phones' OSs were developed by cell-phone makers themselves, their interface designs were different by makers and models. Therefore, I had to read a thick user manual to use it perfectly.
On the other hand, iPhone has very simple user interface. Its interface hierarchy is few. In other words, users can reach the intended function by a few touches, so that they will hardly get lost in the screen.
Why do you think reviews are useful? Do you think informal reviews are more valuable than formal reviews?
Reviews are critically important for improving software development skills because several points of view inspire you and give you new understandings which you don't care.
Informal reviews such as code reviews grow in each individual skills; therefore, this style is especially effective for developing your own products or services.
Formal reviews such as postmortems develop your project team. This style is effective for developing in accordance with customers' RFP. Actually, my company do postmortems for several large projects. They became to pick up potential requirements and non-functional requirements strictly, so that the project members increased accuracy of estimates.
Is there ever a case where a software project milestone is not tied to review? If so, provide one or more examples.
In my company, there are many cases where a software project milestone is not tied to review because the most of our customers focus more on whether a final delivery date is kept strictly or not. However, I think it should be tied to review. If a project milestone is not kept, the project manager should identify the causes: a problem with scheduling from the beginning of the project, project members' low commitment, unclearness on the customers' requirements especially performance and quality requirements, or etc..
