Computer Science and Software Engineering 371

Software Requirements and Specification

Fall 2005

Exam 2 Solution

1. Effort is more straightforward of the two, since it measures how much time and person-power will be required to produce a particular feature, and only so many features can be implemented with time and money allocated.

On the other hand, the higher the risk involved in implementing a feature, the greater the chance that it cannot be delivered regardless of the projected effort involved, meaning that the requirements baseline cannot be completely fulfilled in the final project.

2. (a) The planning game involves both business (marketing) and technical (development) personnel on the project. The business people decide project scope, priority and release dates, while the technical people decide: estimates of effort, technical consequences, process and detailed scheduling. User stories are collected on cards written by the clients; these stories are used to generate tests (extreme programming is a test case-before-code paradigm).

(b) The customers have a simple way of expressing their requirements, and business and technical people are both involved on the vendor side.

(c) The customer interaction required is high (a frequent problem in extreme programming) and supplementary requirements are not covered by the cards.

3. Any request for change in a baselined artifact needs to be considered by the change control board (CCB), which includes representatives from the clients, the product marketing team, and the management of the software project. These artifacts include the software requirements; requests for change to those requirements can be submitted by the customer. In this way, there is a mechanism to ensure that any change to the requirements is considered with a small number of representatives from the major “players” involved in the project. If it is decided that a change in the requirements must be made, then the impact of that change in time and money can be properly assessed, with appropriate action taken.

4. (a) Design constraint, since it is a condition imposed on the development process.

(b) Non-functional requirements, since it involves reliability.

(d) Other requirements, since an RAR file is a physical deliverable of the system.

(e) Design constraint, since it involves conformance to standards.

5. Here is a finite state machine which reflects the different flows for this use case:

From this, there are three scenarios to be considered:

· The user guesses correctly (Basic flow)

· The user guesses incorrectly from a list of three of more options (Alternate Flow 1)

· The user guesses wrong when there are only two options (Alternate Flow 2)

None of these scenarios involves two different things to test involving an “and” or an “or”, so one test case per scenario is acceptable. So, this is what we have so far:

Test Case Id	Scenario	Description	Condition: <condition>	Condition: <condition>	Condition: <condition>	Expected Result
1	1	The user guesses correctly
2	2	The user guesses incorrectly from a list of three of more options
3	3	The user guesses wrong when there are only two options

There are two conditions that need to be considered:

· Whether or not the user selects correctly

· How many options there are (two, or greater than two)

Now we have:

Test Case Id	Scenario	Description	Condition: Guesses correctly	Condition: Number of options	Expected Result
1	1	The user guesses correctly	Yes	N/A
2	2	The user guesses incorrectly from a list of three of more options	No	>= 3
3	3	The user guesses wrong when there are only two options	No	2

Finally, the expected results (derived the different flows) are inserted.

Test Case Id	Scenario	Description	Condition: Guesses correctly	Condition: Number of options	Expected Result
1	1	The user guesses correctly	Yes	N/A	Message that the correct guess was made; termination of use case
2	2	The user guesses incorrectly from a list of three of more options	No	>= 3	Message that the guess was not correct and why; deletion of wrong guess as an option; prompt for another guess
3	3	The user guesses wrong when there are only two options	No	2	Message that the guess was not correct and why; reason for why the other option was right; termination of use case

6. “Yes” was an allowable answer for each of the three questions on the checklist. Below is the most frequently-accepted rationale for “no” in each case:

Does the brief description give a true picture of the use case?

There is no mention of supplying the reason for why an incorrect guess is wrong.

Is it clear how and when the use case’s flow of events starts and ends?

It would be better if Alternate Flow 2 stated that the use case terminates at the end of this flow.

Is there a description of what will happen if a given condition is not met?

There is no discussion of what would happen if the user did not provide an answer within a certain amount of time.

7. Option (a): Without much memory available, it is likely that the data structure used to represent the database is unlikely to mirror its conceptual representation. Also, such a database will require some processing which is not obvious from the software requirements. This means that the form of the requirements and the form of the design are different, making this program somewhat orthogonal.

Option (b): Java is an object-oriented language, and the user interface for the educational is modeling real-world objects (animals), meaning the concept and the design are similar. Also, since the application is interface-oriented, the use cases are likely to be strongly coupled with the detailed design algorithm. Thus, there is not much orthogonality present.

So, option (a) is more orthogonal.