1、ation scripts to obtain customer feedback on our prototypes.13.How is the quality of the documented requirements evaluated? Chapter 14a) We think our requirements are pretty good when we first write them.b) We pass the requirements specification around to people to get their feedback.c) The analyst
2、and some developers hold informal reviews.d) We formally inspect our SRS and analysis models, with participants that include customers, developers, and testers. We write test cases against the requirements and use them to validate the SRS and models.14.How are different versions of the requirements
3、documents distinguished? Chapter 16a) The date the document is printed is generated automatically.b) We use a sequence number, like 1.0, 1.1, and so on for each document version.c) We have an identification scheme that distinguishes draft versions from baselined versions and major revisions from min
4、or revisions.d) The requirements documents are stored under version control in a configuration management system, or requirements are stored in a commercial requirements management tool that maintains a revision history of each requirement.15.How are software requirements traced back to their origin
5、? Chapter 19a) They arent.b) We know where many of the requirements came from.c) All requirements have an identified origin.d) We have full two-way tracing between every software requirement and some voice-of-the-customer statement, system requirement, use case, standard, regulation, architectural n
6、eed, or other origin.16.How are requirements used as the basis for developing project plans? Chapter 15a) The ship date is set before we begin gathering requirements. Were not allowed to change either the project schedule or the requirements.b) We go through a rapid descoping phase to drop features
7、just before the delivery date.c) The first iteration of the project plan addresses the schedule needed to gather requirements, and the rest of the project plan is developed after we have the requirements. We cant change the plan thereafter, though.d) We base the schedules and plans on the estimated
8、effort needed to implement the required functionality. These plans are updated as the requirements change. If we must drop features or adjust resources to meet schedule commitments, we do so as early as possible.17.How are the requirements used as a basis for design? Chapter 15a) If we had requireme
9、nts, we might refer to them during programming.b) The requirements documents describe the solution we intend to implement.c) Each functional requirement is traced into a design element.d) Designers inspect the SRS to make sure it can be used as the basis for design. We have full two-way traceability
10、 between individual functional requirements and design elements.18.How are the requirements used as the basis for testing? Chapter 15a) There is no direct relationship between testing and requirements.b) The testers test against what the developers said they implemented.c) We write system test cases
11、 against the use cases and functional requirements.d) Testers inspect the SRS to make sure the requirements are testable and to begin test planning. We trace system tests to specific functional requirements. System testing progress is measured in part by requirements coverage. 19.How is a software r
12、equirements baseline defined and managed for each project? Chapter 16a) Whats a “baseline”?b) The customers and managers sign off on the requirements, but we still get a lot of changes and customer complaints.c) We define a requirements baseline, but it is not kept current as changes are made over t
13、ime.d) The requirements are stored in a database when an initial baseline is defined. The database and SRS are updated as requirements changes are approved. We maintain a change history for each requirement once it is baselined.20.How are changes to the requirements managed? Chapter 17a) Uncontrolled changes creep in
