1a. Under what circumstances is it appropriate to represent an SRS using informal techniques only?
1b. What can the behavioral specification provide that a requirements document cannot?
1c. If the customer requests that future growth and enhancement ideas be kept, where can these ideas be placed?
1d. What are some items to be included under "data retention" in the SRS?
2. Here are some more examples vague and ambiguous requirements that are vague, incomplete or ambiguous. Provide improve versions of these requirements (make necessary assumption).
a. The tool will allow for expedited data entry of important data fields needed for subsequent reports.
b. The system will provide an effective means for identifying and eliminating undesirable failure modes and/or performance degradation below acceptable limits.
c. The database creates an automated incident report that immediately alerts the necessary individuals.
d. The engineer shall manage the system activity, including the database.
e. The report will consist of data, in sufficient quantity and detail, to meet the requirements.
f. The data provide will allow for a sound determination of the events and conditions that precipitated the failure.
g. The documented analysis report will include, an appropriate, investigation findings, engineering analysis, and laboratory analysis.
h. In section 9.4 of the SRS in Appendix A, which requirements are suitable for representation using the "measurable targets" in the format shown in figure 4.6?
3a. What can be some pitfalls to watch out for in ranking requirements
3b. Describe two different ways to identifying ambiguity in an SRS.
3c. Which of the IEEE Standard 830 qualities seem most important? Can you rank these?
3d. What are the advantages and risks of having requirements engineering conducted (or assisted) by an outside firm or consultants?